Beiträge von Dragonsphere

Zitat von EinEike

Den Brief habe ich heute noch.

Wahnsinn! Das ist ja wirklich der Hammer, dass du das Formular noch hast

29. Oktober 1997... Da war die Welt noch in Ordnung, ich war noch Schüler, mein PC dürfte ein brandneuer 166er AMD K6 gewesen sein (wie ich damals schrieb mit SVGA, Maus und vom Systeminfo anscheinend als 80686 bezeichnet ). Auf den war ich sehr stolz, denn es war zum ersten Mal kein abgelegter PC meines Vaters, sondern ein ganz eigener, für den ich gespart und in den Sommerferien gejobbt hatte. In dem Jahr hatte mich auch mein Physiklehrer dazu ermuntert, programmieren zu lernen und ich machte meine ersten Erfahrungen mit Borland Pascal 7.0.

Und anscheinend kannte ich die Twinoid Shareware nicht von der PC Joker, sondern von einer CD namens "Die randvolle Beilagenscheibe". Aber die PC Joker Ausgabe hatte ich definitv auch, denn ich errinere mich daran, aus dem Menü mehrere der genannten Spiele installiert und angespielt zu haben. LineWars ist da auch so ein Kandidat, an den ich mich erinnere. Und die Shareware von Seek and destroy hatte ich ewig auf der Platte.

Zitat von mac-daniel

Irre dass sich 2 Wildfremde Menschen nach über 25 Jahren im Netz wieder begegnen. Gänsehaut feeling

Absolut genial.

Danke Daryl_Dixon. Dank dem Screenshot kann ich jetzt auch sicher sagen, dass ich das Spiel aus der PC Joker 5/1996 kenne.

Etwa ein Jahr später habe ich dann 20 DM und einen netten Brief an EinEike geschickt, da ich mehr Level und vor allem den Level-Editor haben wollte. Damals alles noch ganz analog per Post Und wohl das erste Mal, dass ich von einer Shareware legal die Vollversion erworben habe

Nach einigem ungeduldigem Warten und regelmäßig in den Briefkasten gucken, kam dann auch ein netter Brief von Eike zurück, mit der Twinoid Vollversion auf Diskette. Damit hatte ich dann auch noch viel Spaß und habe gerne mit Freunden neue Level gebaut.

Also, ein paar sehr schöne Erinnerungen verbinde ich mit Twinoid. Danke dafür, Eike!

Hallo Eike,

ein ganz herzliches Willkommen hier im Forum! Dein Twinoid ist wirklich ein wunderbarer Breakout-Clone! Ich habe das Spiel damals auch als Shareware über eine Zeitschriften-CD (kann gut auch PC Joker gewesen sein) entdeckt und es hat mir so gut gefallen, dass es einer der ganz wenigen Shareware-Titel wurde, von denen ich mir tatsächlich auch die Vollversion gekauft habe. Ich wollte den Level-Editor haben, damit hast du mich gekriegt

Die Diskette habe ich heute noch

Zitat von llm

Ist das nicht eher ein Trieb als Ehrgeiz

Ein Trieb? Eher ein Drang eine Zeit lang dem Alltag zu entfliehen. Unter DOS zu programmieren hat für mich irgendwie etwas sehr entspannendes, fast schon meditatives. Da kann ich super bei abschalten. Alles ist vertaut, überschaubar, langsam und berechenbar. Dann Code zu schreiben und über die gleichen Programmier-Probleme und Lösungen zu grübeln, wie schon vor 25 Jahren, das hat etwas von einer entspannten Zeitreise zurück in eine vertraute Zeit, als das Leben noch einfacher war.

Hinzu kommt dann Ehrgeiz, den unter Windows geschriebenen Code auch unter DOS zum Laufen zu bringen und vielleicht etwas Masochismus, sich dafür unnötiger Weise mit den Limitierungen wie 64 KB Segmenten und einer IDE von 1992 herumzuschlagen (da führen dann manchmal nostalgischen Gefühle und Erinnerungen an die "blaue" Borland IDE zu etwas irrationalen Handlungen)

Zitat von llm

fehlt noch Scrolling und 1Mio andere Sachen

Ja es fehlt noch einiges.

Was wir aber haben sind zwei Header-Dateien mit leicht anzupassendem und auf verschiedenen Betriebssystemen verwendbarem Code für Aufgaben wie das Zeichnen von Landschaftsfeldern und Einheiten aus den originalen Spieldateien. Auch schon gründlich getestet und Fehler bereinigt. Auch das Laden ganzer Kartendaten funktioniert ja schon prima. Hier fehlt nur noch die Behandlung von Gebäuden.

Das ist doch schön eine gute Grundlage und jeder von euch kann auch gerne damit weitermachen. Mein aktueller Quellcode liegt ja dabei.

Zitat von Nelson

Hab die DOS Version heute getestet. Funktioniert gut.

Ja, unter DOSBox muss man die Cycle etwas hoch stellen, aber sonst läuft die gut, auch auf meinem 486er und ist schonmal eine gute Basis für den Editor, auf die man doch aufbauen kann..

Mit Qt fremdel ich dagegen noch etwas. Da musste ich dann doch erstmal die ein oder andere Funktion nachlesen und in Quellcodes stöbern. Habe bisher noch auf ein zusätzliches Menü verzichtet und hatte dann auch noch mit einigen blöden Bugs zu kämpfen, bis das Anzeigen einer Karte in einem Fenster endlich korrekt klappte.

Meinen Code zum Laden einer Karte an DOS und VGA anzupassen, war dagegen ein Kinderspiel und für mich vertautes Gebiet. Das konnte ich so runterschreiben. Etwas Fleißarbeit alle Speicherzugriffe umzubauen (habe mich zum Glück an die Möglichkeit der Huge-Pointer in C++ erinnert und umschiffte so die 64 KB Segment-Probleme ) und dann von Bitmap Objekten usw. auf simple Screenbuffer und deren Kopieren in den Bildschirmspeicher umstellen. Aber das war es dann im Wesentlichen auch schon. Daher war der DOS-Port dann doch recht schnell gemacht und ist schon ein bisschen weiter, mit Config-Datei und so

Zitat von llm

@Dragonsphere

noch weiter gekommen - du scheinst ja genau so ausgebucht zu sein wie ich

Ja, Freizeit ist leider aktuell kaum vorhanden

Ein bisschen Code habe ich aber zwischenzeitlich trotzdem zustandegebracht.

Mit Qt habe ich ein bisschen rumprobiert und den Mapviewer nochmal in Qt umgesetzt. Das Laden der Ressourcen direkt aus dem Spiel und das Anzeigen einer Karte funktioniert gut.

HL-Editor_Win_Qt.zip

Achtung: Der Pfad zum Spiel steht hier aktuell noch mit in den Kostanten im Quellcode und muss entsprechend angepasst werden.

Und dann hat mich neulich der Ehrgeiz gepackt und ich habe direkt mal einen DOS-Port davon gemacht, bzw. den Code für DOS angepasst.

Funktioniert auch gut. Hier steht der Pfad zum Spiel in der HLMVIEW.CFG, kann also angepasst werden, ohne neu kompilieren zu müssen.

Die Nummer der zu ladenden Karte könnt ihr als Kommandozeilenparameter angeben. Mit den Cursortasten könnt ihr den Kartenausschnitt scrollen. Mit Tab zwischen Sommer/Winter wechseln

HLMVIEW_DOS.zip

Also ein Grundgerüst steht und als nächstes müsste eine schöne Editor-Oberfläche kommen. Aktuell fehlt mir nur total die Zeit dafür.

Das hier finde ich auch noch ein sehr hilfreiches Beispiel:

GitHub - vpapadopou/qt-simple-paint: A simple paint program built with Qt Creator in C++

A simple paint program built with Qt Creator in C++ - GitHub - vpapadopou/qt-simple-paint: A simple paint program built with Qt Creator in C++

github.com

Sehr übersichtlich und da ist auch der Datei-Dialog und das zeichnen im Fenster nochmal gut drin.

Vielleicht gucke ich mir den Qt Creator auch noch an, wenn ich etwas Zeit finde. Scheint ja eine schön schlanke IDE zu sein.

Zitat von llm

@Dragonsphere

bist du mit meiner Beschreibung zum Qt-Kram-Bauen zurecht gekommen?

Ja, soweit schon. Ich habe es nach deiner Anleitung recht problemlos geschafft, alles zu installieren und kann das Game of Life Beispiel auch erstellen.

Hatte nur erst das Problem, dass noch Einträge in der PATH Vairabe fehlten und er deshalb zunächst Dateien nicht fand. Das war ja aber schnell zu beheben.

Nur, wenn ich mir jetzt eine Kopie des Projekts machen will, um es vom Game of Life zu unserem HL Editor umzubauen, dann renne ich noch in einen Haufen Fehlermeldungen.

Habe mir daher noch die Qt Tools for Visual Studio installiert, womit ich ganz komfortabel aus Visual Studio ein neues Qt Projekt erstellen kann. Das klappt schon mal gut.

Nachher versuche ich mal Code aus dem Game of Life in mein neues Projekt zu kopieren und eine Basis für unseren Editor zusammenzubasteln.

Hallo grohfuda, danke für's mitraten

Zitat von grohfuda

ich denke ich sollte mir zeitnah auch mal einen Hex-Editor besorgen um nicht nur zu spekulieren

Unbedingt! Ein Hex-Editor ist nie verkehrt.

Unter Windows kann ich dir den HxD empfehlen. Recht leistungsfähig, trotzdem übersichtlich, gibt es auch auf deutsch und ist kostenlos (gibt nur eine kleine Bitte um Spenden im Info Feld).

Den gibt es hier: https://mh-nexus.de/de/hxd/

Zitat von grohfuda

Zeitpunkt wann die Einheit eingeführt wird (Einheitenvorstellung zu Beginn der Karte ggf. als Kartennummer) wie D/Fr kodiert wird ist herauszufinden

Das ist aber auch schon über die Karten selbst ganz gut geregelt. In den .shp Dateien ist ja für jede Karte genau definiert, welche Einheiten zur Verfügung stehen.

Zitat von grohfuda

Könnten in 40 ggf. auch Produktionskosten codiert sein?

Habe gestern Abend noch mal etwas auf die Daten geguckt und Offset 40 scheint die Ladekapazität von Transportfahrzeugen zu sein. Hier steht 09 bei Transportwagen, F bei Truppentransport, 1E Transportschiff und bei allen anderen Einheiten 0

Mit den Werten der Unit.dat habe ich neulich auch noch ein bisschen rumprobiert.

Hier ist aber noch viel unbekannt. Mein Stand jetzt:

grohfuda, das ist sogar sehr interessant!

Wir haben ja schon rausgefunden, dass die Daten-Dateien des Spiels sich zwischen PC und Amiga-Version nicht großartig unterscheiden. Es dürfte also (mit den hier gesammelten Infos) kein Problem sein, die neuen Karten aus der Leveldisk mit der PC Version zu verwenden.

Ich habe gerade in der Install Anleitung der Leveldisk gelesen, dass diese 15 alte Karten durch 15 neue Karten ersetzt. Brigt uns also leider keine neuen Infos dazu, wie man neue Karten mit neuen Passwörtern hinzufügen könnte.

Da bin ich aber inzwischen ein kleines bisschen weiter gekommen.

Wir haben ja unsere Codes.dat im Spielverzeichnis, die entpackt 10 Byte Infos für jede Karte enthält:

Offset(h) 00 01 02 03 04 05 06 07 08 09

00000000  20 25 1C 23 15 02 01 01 00 00   %∟#§☻☺☺..
0000000A  13 19 26 19 1C 02 01 01 02 00  ‼↓&↓∟☻☺☺☻.
00000014  1D 1F 25 23 15 02 01 01 02 00  ↔▼%#§☻☺☺☻.
...

Offset 0 - 4: Passwort, leicht verschlüsselt (10h vom Wert des Bytes abziehen und man erhält die Nummer des Buchstabens im Alphabet).

Offset 5 : Bedeutung unbekannt, hat immer den Wert 2

Offset 6 : Typ der Karte, 1 für Kampagne, 2 für 2-Spieler.

Offset 7: Bedeutung unbekannt, hat fast immer den Wert 1, nur bei der letzten Kampagnen Karte und bei der letzten 2-Spieler Karte 0.

Offset 8: Jahreszeit 0 = Sommer, 2 = Winter.

Offset 9: Unbekannt, immer 0

Da haben wir also die Info, die ich noch dringend suchte und können für neue Karten auch einstellen, ob sie im Sommer oder Winter spielen

Und... Es funktioniert eine neue Kartendatei im MAP-Ordner zu erstellen (also eine 72.fin und 72.shp zu ergänzen) und einen neuen Eintrag hier in der Codes.dat anzuhängen!

Danke für die ausführlichen Infos llm

Werde am Wochenende mal versuchen alles einzurichten. Bisher bin ich da leider nicht zu gekommen.

Für den Karten-Editor sollte das gameoflife Beispiel wirklich eine gute Grundlage sein.

Jetzt habe ich es mir nach dem Post hier nochmal angeguckt und den Code sogar noch vor Ende meiner Mittagspause geknackt:

"A" ist 0x11 (17 dezimal) und dann geht es einfach weiter bis 0x30 (42) für "Z".

Und schon kommt man auf "20 25 1C 23 15" für "PULSE".

Zitat von grohfuda

1. Sollen die neuen Karten eigene Levelcodes erhalten oder sollen die bisherigen Karten ersetzt werden? Es ist wahrscheinlich einfacher, die bisherigen Karten zu ersetzen.

Dazu habe ich mir auch gerade erst wieder Gedanken gemacht und ein bisschen in den Spieldateien gestöbert. Wer hat Lust, sich mal die CODES.DAT genauer anzusehen?

Da scheinen nämlich die Levelcodes in verschlüsselter Form drin zu stehen und sogar noch ein paar Infos mehr. Es scheinen 10 Byte Abschnitte zu sein (die Datei ist entpackt genau 720 Byte groß und es gibt 72 Karten...) Da die Codes aber nur 5 Zeichen lang sind, steht hier mit etwas Glück auch, welche Kartendatei damit geladen werden soll und ob die Sommer- oder Wintergrafik verwendet wird

So sieht die (entpackte) Datei im Hex-Editor aus:

Offset(h) 00 01 02 03 04 05 06 07 08 09

00000000  20 25 1C 23 15 02 01 01 00 00   %∟#§☻☺☺..
0000000A  13 19 26 19 1C 02 01 01 02 00  ‼↓&↓∟☻☺☺☻.
00000014  1D 1F 25 23 15 02 01 01 02 00  ↔▼%#§☻☺☺☻.
0000001E  26 15 1E 1F 1D 02 01 01 00 00  &§▲▼↔☻☺☺..
00000028  1E 1F 19 23 15 02 01 01 00 00  ▲▼↓#§☻☺☺..
00000032  22 19 17 18 24 02 01 01 00 00  "↓↨↑$☻☺☺..
0000003C  1F 22 1B 11 1E 02 01 01 00 00  ▼"←◄▲☻☺☺..
00000046  16 22 1F 1E 24 02 01 01 00 00  ▬"▼▲$☻☺☺..
00000050  22 11 24 19 1F 02 01 01 02 00  "◄$↓▼☻☺☺☻.
0000005A  20 11 22 24 23 02 01 01 02 00   ◄"$#☻☺☺☻.
00000064  20 1C 11 1E 15 02 01 01 00 00   ∟◄▲§☻☺☺..
0000006E  16 1C 11 1D 15 02 01 01 00 00  ▬∟◄↔§☻☺☺..
00000078  17 1F 24 18 11 02 01 01 00 00  ↨▼$↑◄☻☺☺..
00000082  12 11 1C 1F 1E 02 01 01 02 00  ↕◄∟▼▲☻☺☺☻.
0000008C  20 11 25 23 15 02 01 01 02 00   ◄%#§☻☺☺☻.
00000096  15 1C 19 24 15 02 01 01 00 00  §∟↓$§☻☺☺..
000000A0  19 1E 16 22 11 02 01 01 00 00  ↓▲▬"◄☻☺☺..
000000AA  18 19 1C 1C 23 02 01 01 00 00  ↑↓∟∟#☻☺☺..
000000B4  13 1F 12 22 11 02 01 01 00 00  ‼▼↕"◄☻☺☺..
000000BE  11 24 1C 11 23 02 01 01 02 00  ◄$∟◄#☻☺☺☻.
000000C8  11 1D 20 15 22 02 01 01 02 00  ◄↔ §"☻☺☺☻.
000000D2  22 18 15 19 1E 02 01 01 00 00  "↑§↓▲☻☺☺..
000000DC  13 11 1E 14 1C 02 01 01 00 00  ‼◄▲¶∟☻☺☺..
000000E6  23 24 15 22 1E 02 01 00 01 00  #$§"▲☻☺.☺.
000000F0  12 11 24 1C 15 02 01 01 00 00  ↕◄$∟§☻☺☺..
000000FA  17 1F 1F 23 15 02 01 01 02 00  ↨▼▼#§☻☺☺☻.
00000104  23 20 1F 22 24 02 01 01 02 00  # ▼"$☻☺☺☻.
0000010E  12 19 1D 12 1F 02 01 01 00 00  ↕↓↔↕▼☻☺☺..
00000118  24 15 1D 20 1F 02 01 01 00 00  $§↔ ▼☻☺☺..
00000122  12 11 22 1F 1E 02 01 01 00 00  ↕◄"▼▲☻☺☺..
0000012C  12 25 1D 1D 1D 02 01 01 00 00  ↕%↔↔↔☻☺☺..
00000136  1C 15 26 15 1C 02 01 01 00 00  ∟§&§∟☻☺☺..
00000140  24 1F 28 19 1E 02 01 01 02 00  $▼(↓▲☻☺☺☻.
0000014A  20 22 19 1E 13 02 01 01 02 00   "↓▲‼☻☺☺☻.
00000154  13 1C 15 11 1E 02 01 01 00 00  ‼∟§◄▲☻☺☺..
0000015E  28 15 1E 1F 1E 02 01 01 00 00  (§▲▼▲☻☺☺..
00000168  23 19 17 1E 23 02 01 01 00 00  #↓↨▲#☻☺☺..
00000172  18 1F 25 23 15 02 01 01 02 00  ↑▼%#§☻☺☺☻.
0000017C  23 19 17 1D 11 02 01 01 02 00  #↓↨↔◄☻☺☺☻.
00000186  23 15 26 15 1E 02 01 01 00 00  #§&§▲☻☺☺..
00000190  2A 1F 1D 12 19 02 01 01 00 00  *▼↔↕↓☻☺☺..
0000019A  1D 1F 26 15 23 02 01 01 00 00  ↔▼&§#☻☺☺..

Nur wie kommt man von "%∟#§" zu "PULSE"?

Zitat von grohfuda

2. Wie sieht es mit den "Strategieanweisungen" der KI aus. Gibt es hier schon weitere Erkenntnisse? (Ich weiß das ist ein Thema für später, wenn der Editor funktionsfähig ist)

Bisher leider nicht. Es ist ja auch nur eine Theorie, dass die *.COM Dateien im MAP Ordner Daten für den Computergegner enthalten. Leider ist das ja schwer festzumachen, denn es ist ja nicht so, dass der Computer bei den Kampagnen-Karten eindeutig intelligenter vorgehen würde (auch wenn er bei manchen 2-Spieler-Karten total versagt). Du kannst ja mal Dateien austauschen, zum Beispiel die 00.COM mit der 47.COM , und vergleichen, ob der Computergegener dadurch dann andere Züge macht/anders vorgeht, als vor dem Dateitausch.

Zitat von grohfuda

3. Kann man die erwähnten "fehlenden" Einheiten, die von Bluebyte nicht verwirklicht wurden, vielleicht im Editor ergänzen? Ich dachte da z.B. an einen Zeppelin (verbesserter Ballon, der kämpfen kann) oder an einen Kreuzer (als Seekampfeinheit zwischen Zerstörer und Schlachtschiff), oder ggf. auch ein zweites Uboot.

Hier muss ich meine ursprüngliche Annahme, dass da Einheiten fehlen, korrigieren. Das schien erst so, aber es liegt einfach daran, dass es ja Einheiten gibt, die zwei Felder belegen. Für die braucht es ja zwei Grafiken und daher auch zwei Nummern. Da das Spiel aber zum Beispiel ein Schiff nur zeichnet, wenn die erste Nummer in der Karte steht, schien es erstmal so, als ob da Einheitengrafiken fehlen.

Zitat von grohfuda

4. Gibt es schon Ideen, wo wir die vielen fertige Karten sammeln, um diese der Fangemeinde zugänglich zu machen?

Mach mal einen Vorschlag

Schön wäre ja auch ein (zusätzlicher) Thread hier im Forum dafür, wo man seine Karte vorstellen und dazu schreiben kann, was man sich dabei so gedacht hat

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.

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.

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...

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?

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

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