Re: problem emulator
Hey, wait! This sounds like a task suitable for me!
Mayo, you seem to already have the necessary knowledge about the different formats. Could you pass that over to me? Then I should be able to write the tool. Is that a deal?
Hey, wait! This sounds like a task suitable for me!
Mayo, you seem to already have the necessary knowledge about the different formats. Could you pass that over to me? Then I should be able to write the tool. Is that a deal?
@Fawlty
Ich schreibe einfachshalber mal in deutsch
Gute Idee, wenn Du die Sache mit dem Konvertier-Tool in Angriff nehmen willst, dann wäre das leidige Thema mit den verschiedenen Emulator-Versionen und so kein Problem mehr (man könnte dann wirklich ALLE Emulatoren benutzen, die das ST/ADF-Format benutzen) :-) Und wenn Du Lust hast, könntest ja auch noch eine Funktion einbauen, wo man die Tower-Gruppen auch in das Tob Remake-Format exportieren kann. Die Daten dazu würde ich Dir geben bzw. im hier angehängten C#-Beispielcode findest Du die Klassen/Methoden für das RToB Tower-Format.
Also, erst einmal:
Beide Formate für den Atari (ST) und Amiga (ADF) sind ja Images der Disketten und enthalten die Daten der einzelnen Tracks und Sektoren in unkomprimierter Form. Das heisst, wenn Du ein Tool schreiben willst, dass die Konvertierung der selbsterstellten Towergruppen zwischen ADF <-> ST ermöglichen soll, dann musst Du Dich erst über die beiden Image-Formate informieren (Aufbau Tracks und Sectors) und dann eine Routine schreiben, mit der Du das Diskettenverzeichnis auslesen kannst (im beigelegten Archiv habe ich ein provisorisches Test-Tool (TobImport) in .NET C# beigelegt, mit dem ich das Verzeichnis von ST Save-Disks ausgelesen (für die Spielstände) habe bzw. eine Original-ToB-ST-Disk ausgelesen habe, um die Original-Level ins TobRemake-Format zu konvertieren.
Pete benutzte für die Speicherung der Tower-Daten ein sehr sehr kompaktes Format. In weniger als 512 Bytes passen die Daten eines Towers. Für die Speicherung der Daten benutzte er Datentypen mit variabler Bitbreite (zum Beispiel für den Tower-Titel 7Bit-breiten ASCII-Code), für den statischen Tower mit den Basis-Elementen (FLOOR,BOX,UP/DOWN LIFT) benutzte er 3Bit-Werte und für dynamische Objekte (max. 14) wie Hopper, etc. benutzte er 14Bit-breite Werte. Du musst also die Tower-Daten nicht byte-weise, sondern bit-weise auslesen.
In der Text-Datei "level-format-original.txt" habe ich mal die verschiedenen Offsets (die stimmen nicht unbedingt, musst du also evtl. selber durch probieren nochmal korrekt ermitteln) für die verschiedenen Daten mit den entsprechenden Bedeutungen und Bitbreiten und Grössen hinterlegt. Bis auf Offsets, Sektoren/Trackzahl, Verzeichnis-Format und die Bitbreite bei den Farben für die Towers dürften sich die Towergruppen auf den Images nicht grossartig unterscheiden.
Ich würde für beide Image-Formate verschiedene Save-Disks mit unterschiedlichen Inhalten nehmen und erst versuchen, die Verzeichnisse korrekt auszulesen, und dann versuchen, die Start-Tracks/Sektoren der enthaltenden Towergruppen zu ermitteln.
Wenn Du soweit bist, hast Du schon eine Menge geschafft, danach würde ich dann für beide Formate durch Probieren ermitteln, wo die einzelnen Daten wie Tower-Titel und Author, Basis-Elemente, normale Elemente und Zusatzdaten wie "Finishing conditions" liegen.
In welcher Sprache dachtest Du denn, das zu programmieren? Und als Konsolen-Anwendung über Befehlsparameter zu steuern (wer ja am einfachsten) oder eine eigene Fensteranwendung draus zu machen?
Zitat:
dann musst Du Dich erst über die beiden Image-Formate informieren (Aufbau Tracks und Sectors)Ich hatte gehofft, GENAU DAS hättest Du schon erledigt.......
Naja, dann werd ich wohl mal ein bißchen tüfteln müssen. Aber erst nach Weihnachten. Bis dahin ist noch sooooooooo viel anderes zu tun..... *uff*
Zitat:
In welcher Sprache dachtest Du denn, das zu programmieren? Und als Konsolen-Anwendung über Befehlsparameter zu steuern (wer ja am einfachsten) oder eine eigene Fensteranwendung draus zu machen?Eigentlich wäre das mal ein prima Einstiegsprojekt für Java, aber wahrscheinlich werd ich's dann doch in C++ machen. Vielleicht auch beides...
Naja, Parametersteuerung wäre ja eher für Batches sinnvoll, aber da sicherlich nur relativ selten mal 'ne Konvertierung gemacht werden muß, wär' das Quatsch. Und 'ne Oberfläche macht einfach mehr her, und ich mach doch sowas so gerne....
Achso, mit MFC und WinAPI quäle ich mich immer etwas Fensteranwendungen mache ich dann doch lieber mit .NET C# und VB (also mit dem Form-Designer), wenn eine Fensteranwendung aus mehr wie 1-2 Dialogen besteht
Zitat:
Achso, mit MFC und WinAPI quäle ich mich immer etwas. Fensteranwendungen mache ich dann doch lieber mit .NET C# und VB (also mit dem Form-Designer), wenn eine Fensteranwendung aus mehr wie 1-2 Dialogen besteht Ach was, ist doch ganz easy mit MFC. Da kann man ja auch den Ressourcen-Editor vom Visual Studio nehmen.
Das Hauptprogramm von dem Projekt, an dem ich in der Firma arbeite, hat über 140 Dialoge........ *gg*
Fast schon SAP-Verhältnisse. Besonders übersichtlich wird das Ganze dann dadurch, daß es in 23 Sprachen übersetzt wird...