Level-/Karteneditor für Historyline 1914-18

Zitat von llm

Zitat von Dragonsphere

Habe am Wochende die Zeit gefunden mal Visual Studio einzurichten und etwas Code zu schreiben

sollten Map.x und Map.y auf dem Screenshot nicht eher width und height sein?

Da postet man einmal einen Screenshot und schon werden hier die paar Zeilen Code im Hintergrund analysiert

Aber ja, width und height wäre hier natürlich korrekt. Werde ich entsprechend anpassen. Wie geschrieben habe ich erstmal nur etwas rumprobieren wollen und da war ich an der Stelle wohl etwas schreibfaul.

Das ganze basiert auch auf den Standarddateien, die Visual Studio für eine Windows Desktopanwendung generiert und hat noch so einige Macken.

Zitat von llm

Zitat

Ich habe erstmal nur etwas rumprobiert. Ist auch mein erstes Windows-Projekt seit bestimmt 10 Jahren, da musste ich mich erstmal wieder etwas reindenken.

stell einfach mal ein Zip ein dann kann ich das CMaken und auch linuxen

llm, hier, wie gewünscht, der aktuell Stand mit allen Dateien als ZIP. Ich habe inzwischen noch 2x Skalierung der Bitmaps und Scrollen ergänzt.

Damit es funktioniert, muss in der MapViewer.cpp bei den globalen Variablen den Pfad zu HL1914-1918 angepasst werden. Einen Datei-Öffnen-Dialog gibt es aktuell noch nicht.

lib.h enthält alles, um die Bitmaps für Gelände und Einheiten einzulesen und zu zeichnen.

fin.h entsprechend alles, um eine Karte zu lesen und zu zeichnen.

Der Code in den beiden Dateien sollte sich auch recht problemlos für andere Systeme verwenden lassen.

Edit: Die kompilierte EXE im x64\Debug Ordner funktioniert natürlich nicht, da sie meine Pfadangaben verwendet. Ich habe hier aber zum Testen auch nochmal die Spieldateien in gepackter und ungepackter Form abgelegt.

Zitat von llm

Zitat

hier, wie gewünscht, der aktuell Stand mit allen Dateien als ZIP.

schon lange nicht mehr bare Metal Win32 API in neuem Code gesehen

das lässt sich natürlich nicht ganz so einfach auf Linux oder DOS portieren

schon eine Strategie: also Qt (auf jeden Fall Multiplatform) oder irgendwie sowas, oder selbst gemalte Pixel-Oberflächen und damit auch DOS kompatibel?

Alles anzeigen

Ja, die Mapview.cpp ist schleet portierbar. Wie gesagt, hatte ich dafür jetzt erstmal einfach Visual Studios Windows API Vorlage genommen, um ein bisschen auszuprobieren. War auch erstmal mehr als Test für die beiden Header-Dateien gedacht, die bis auf Verweise auf HDCs auch keinen Win32 API Code beinhalten, was ja leicht durch entsprechende Screenbuffer bzw. Pointer/Handle ersetzt werden kann.

Den ganzen "Fenster-Kram" bräuchte man ja für DOS sowieso nicht. Da brauchen wir ja sowie eine andere Oberfläche und damit ein eigenes Hauptprogramm.

Um für DOS das Speichermanagement mit möglichst geringem Aufwand anzupassen, würde ich einfach mit dem oberen Speicherbereich arbeiten und XMS verwenden.

Mit Qt habe ich noch nichts gemacht, gucke ich mir aber natürlich gerne an.

Zitat von llm

Code

//Ein Hexfeld hat einen Durchmesser von 24 Pixeln

ist das nicht eher die Seiten/Kantenlänge?

Es ist eine Seitenlänge der quadratischen Tile-Grafik und damit der Durchmesser des Felds von einer Außenkannte zur anderen:

Zitat von llm

baut

hab noch byte durch byte_t ersetzt - beisst sich mit std::byte wenn man aktuellere C++ Standards verwendet und das böse "using namespace std" macht

Dieser "böse" Code macht aber vieles auch lesbarer und stand damals sogar als quasi Standard für den Beginn jedes C Programs in meinem Lehrbuch. Würde man heute vermutlich nicht mehr so in ein Tutorial schreiben.

Den und die 16 Bit Datentypen habe ich aus Faulheit, beim kopieren des unter DOS mit Borland C++ geschriebenen Codes, mitgenommen. Ist sonst ja auch ein bisschen schwierig, wenn ein int auf einem anderen System plötzlich deutlich größer ist.

Daher kam übrigens auch die cpp Dateiendung für eigentlichen C Code, die du hier mal angemerkt hast. Wenn ich in der alten Borland IDE im Code IOSTREAM verwende, ist es für den alten Compiler sofort C++ und er kann das nur verarbeiten, wenn die Dateiendung auch cpp ist.

Ich sollte mir wohl mal einen moderneren Compiler unter DOS installieren

Zur Musik habe ich auch noch ein paar neue Erkenntnisse:

Nach dem Setzen der Instrumentdaten beginnt die eigentliche Musiksequenz in der MNU.ADL ja mit einem Befehl, der im OPL-2 Output nicht zu finden war:

Zitat von Dragonsphere

60 06 A9

War nicht zu finden...

Eventuell Timing über den PIT und daher nicht in den OPL-2 Befehlen?

Im Header der ADL Dateien findet sich in den letzten beiden Byte (also Offset 0x18 und 0x19) allerdings dazu passend auch der Wert A9 06

An späterer Stelle findet sich in den ADL folgender Befehl.

Zitat von Dragonsphere

E9 23 24

Timer des OPL-2 wird programmiert und Register 43 -54 erhalten neue Werte

Das Programmieren des Timers sieht in der RAW so aus:

00 02 = Clock change Befehl im RAW Format

A9 06 = Wert der geschrieben wird, wieder unsere A9 06!

Die Modding Wiki verrät uns:

To convert the clock speed to a Hertz measurement (Hertz is cycles per second, and the delays are in units of one cycle), use this formula: 

iHertz = 1193180.0 / iClockSpeed

0xA906 = 43.270

1193180 /43270 = 27 Hz

60 ist also wohl der Befehl für "Change Timer" in den ADL Dateien und zu Beginn der Sequenz wird hier das Timing auf 27 Hz geändert, was zudem die vorgesehene Timerfrequenz laut Header ist.

Der Playercode im Spiel scheint diesen Befehl aber zunächst zu ignorieren, aber an späterer Stelle, beim ersten E9 Befehl auszuführen.

Der E9 Befehl bzw. was dazu in den RAW Daten steht, war mir ja eh noch ein Rätsel. Es scheint aber schlichtweg eine Art Wartebefehl für das Timing zu sein.

Nach diesem Befehl folgen im Raw-OPL-Code auch mehrere Delays, aber gerade bei den ersrten auch eine Verringerung der Lautstärke, weshalb ich zunächst an einen Effekt wie Volume Slide gedacht habe.

Insgesamt wird nach jedem Befehl E9 aber 105 Ticks (in der MNU.ADL) gewartet, bevor ein Note-Off Befehl folgt. Was ja Sinn macht.

Die Programmierung des Timers würde dann beim ersten Wartebefehl erfolgen. Auch das macht ja Sinn.

E9 wäre dann das Pendant zur "delta time" bei Midi. Allerdings finde ich in den Musikstücken immer nur E9, nie E8 o.ä. und es folgt auch kein Datenbyte darauf. Und der Player würde dann in "Wartezeiten" von sich aus die Lautstärke verringern, also so eine Art Fade out starten...

Was wir jetzt aber über das ADL Dateiformat von BlueByte wissen:

Header

(hier von MNU.ADL)

Es fehlen uns noch die Angaben zur Geschwindigkeit des Songs, neben dem Timer-Wert. So etwas wie BPM oder, analog zu Midi, ticks per quarter-note. Diese Infos dürften hinter den noch zu klärenden Bytes stecken.

Die Musiksequenz funktioniert ähnlich wie Midi, allerdings mit eigenen Befehlen und eng angepasst an den OPL-2:

Ich versuche mich demnächst mal an einem Player.

Zitat von llm

oder willst du zwingend super-alte Systeme supporten?

DAS fragst du in DIESEM Forum?!

Auf die Gefahr hin, dass die 286er Fangemeinde jetzt aufheult, denke ich aber, dass 386er als Mindestanforderung wohl klar geht.

Welche Anforderungen hat da eigentlich das Spiel selbst? Hat jemand zufällig die Packung zur Hand?

Zitat von 919guy

Zitat von Dragonsphere

Welche Anforderungen hat da eigentlich das Spiel selbst? Hat jemand zufällig die Packung zur Hand?

Die Packung nicht, aber im Handbuch steht mindestens ein 80286 mit VGA und 7MB Speicherplatz auf der HDD. Das ganze dann ab DOS 3.3.

Danke. Hmmm, dann wäre ja 286er Unterstützung doch schon schön...

Ach ja, der Stunts-Editor... Was habe ich da früher Stunden mit zugebracht

Wir hatten hier im Thread ja auch schon die Idee für die DOS Version, einfach die Game.iff aus dem Spie zu nehmen.

Das ginge ja genau in die Richtung:

Links die Karte und Rechts die verfügbaren Geländegrafiken und Einheiten.

Schön wäre aber natürlich auch eine Übersichtskarte und irgendwie müssen wir dann noch die Möglichkeit, Gebäude zu editieren, einbauen.

Und die Windows-Version braucht ja trotzdem eine Fensterklasse und es wäre ja schön, die Bitmapfunktionen von Windows zu nutzen und da nicht das Rad neu erfinden zu müssen.

Aber natürlich wäre der Portier-Aufwand wesentlich geringer, als bei Verwenudng von Windows-Fenstern bzw. der Windows API.

Der Aufwand wird für die DOS Version dann deutlich größer.

Die Oberfläche und Steuerung müsste für DOS komplett neu geschrieben werden. Aber viel von dem Code dahinter, wie der Code zum Lesen/Schreiben der Spieldateien, Logik zum Anwählen von Hex-Feldern usw. lässt sich ja trotzdem recht gut übernehmen und darauf dann einen kleiner Editor im Spieldesign und 320x200 zu bauen, ist doch machbar und neben einer komfortableren Desktopversion für Windows und Linux zu realisieren.

Die DOS Version wird dann halt für die Puristen.