Hallo,
ich suche nach jemanden welcher mir technische Details zum Dulog System beantworten kann, da leider die beiden Hauptentwickler nicht mehr am Leben sind.
Zum Hintergrund:
Das genaue Jahr kann ich nicht mehr nachvollziehen, aber es muss so 2010 gewesen sein, da fing ich an meine persönliche Biing! Version zu frisieren. Zunächst nur den Kontostand, dann wurden Personal- und Patientendaten frisiert. Dafür schrieb ich ein kleines Tool, welches es mir ermöglichte die Grafiken auszulesen, womit ich theoretisch dann auch die Passfotos ändern konnte. Später konnte ich die beiden Dateien BITEXPZ und BIDATP dechiffrieren und die Idee von Biing4Win war geboren, die Nachprogrammierung von Biing!. Ich schrieb einen Editor sowie den passend Spielclient und eine Art Engine, welche ich BiingEngine taufte. Diese funktioniert so weit. Die Grafiken konnten angezeigt und mit diesen interagiert werden. Was fehlte, war die komplette Spiellogik. Das Reverse Engineering viel Zeit und vor allem Wissen braucht, wollte ich die Logik selber nachahmen. Dies fühlte sich jedoch falsch an und machte, allein wegen der komplexen Textbausteine einen riesigen Aufwand.
So versuchte ich mich doch am Reverse Engineering von Biing, scheiterte aber kläglich. Im Laufe der Zeit passierten nur wenige kleine Anpassungen, denn das größte Problem blieb. Die Implementierung der Spiellogik welche eben sehr sehr nah am Original bleiben soll. So schlief das Projekt endgültig ein. Die BiingEngine welche ich damals angefangen hatte wurde für andere Sachen weiterverwendet und hat eine Menge dazugewonnen.
Dieses Jahr 2024, musste ich mein Repository umziehen und stieß wieder auf das Biing4Win Projekt. Aus Interesse, ob diese (letzte angepasste) Version von 2016 noch mit der 2024 Version der BiingEngine lief, probierte ich dies aus und es lief auf Anhieb. Dadurch bekam ich, mal wieder, Lust auf Biing! sowie am Projekt. Fing an mit Nachforschungen über Reverse Engineering für DOS Programme. Welche mittlerweile ziemlich limitiert sind, da es kaum noch Tools und Informationen gibt. Auch kann ich nicht Vollzeit daran arbeiten, sondern eher so ein paar Stunden pro Monat. Ich stieß immer auf ein Problem DULOG.
Daher zu meinen Fragen:
Was ist DULOG, was macht es und wie wurde es implementiert.
Ich habe dazu meine eigenen Erkenntnisse, aber vielleicht findet sich jemanden mit wem ich mein Wissen teilen bzw. dieses erweitern kann.
Biing!/Dulog technische Dinge
Moderatoren: Xajorkith, erni, Asgard
-
dragonling
- Hexer/Hexe
- Beiträge: 857
- Registriert: Mo 11.08.2003 - 05:50
- Wohnort: Hanau
- Kontaktdaten:
Re: Biing!/Dulog technische Dinge
Hi,
vielleicht kann ich etwas dazu sagen, da ich ab ca. 2007 sehr viel Zeit mit dem Analysieren von Biing2(A), Fate 2 und Dynatech 2 verbracht habe. So viel, daß ich später auch die Dateien sauber auslesen und modifizieren konnte, so daß ich nach Olafs Tod die verschiedenen Versionen noch eine zeitlang interessierten Spielern weiterhin personalisiert zur Verfügung stellen konnte. Anekdote: Der ursprüngliche Auslöser dafür war, daß Olaf in Fate2 die Startbildschirm-Grafik geändert hatte und ich aber die alte wieder haben wollte
Außerdem habe ich tonnenweise die Datenstrukturen in den Spielen analysiert und dekodiert. Zur Spiellogik kann man sagen, daß Olaf - nach eigener Aussage - sehr viel mit Zufall und Parametern gearbeitet hat, so daß er am Ende selbst nicht mehr wußte, was das Spiel tat. Denn er wollte seine Spiele auch selber spielen.
Er hat mir auch mal einen Teil vom Biing2-Sourcecode zukommen lassen (>1MB Assembler) - wie gesagt, nur ein Teil des Codes - weil ich ihm helfen sollte, seine Hilfstools zu modernisieren - leider war dies 2011 und es wurde nichts mehr daraus.
Und obwohl ich den Assemblercode problemlos lesen kann, kann ich sagen, daß es wirklich eher sinnvoller ist, ein Rework neu aufzubauen, als den Code (die EXE) zu disassemblieren.
Nun zu Deiner Frage: DULOG.
Das DULOG ist eine einfache GameEngine, die von Holger Gehrmann ebenfalls in Assembler erstellt und weiterentwickelt wurde. Das DULOG enthält den grundsätzlichen GameLoop, nimmt die Eingaben entgegen, baut die Grafikausgabe auf und gibt Sounds und Musik (eigener MIDI-Sequenzer) aus.
Die Daten sind in Archiv-Dateien zusammengefaßt - aber das weißt Du ja schon. Die Grafiken haben einen Header, der das Format beschreibt. Sie sind teilweiese auch transparent. Die WAV-Daten haben alle dasselbe Format (SamplingRate, Bits). Die Musik liegt in eigenen Dateien im MIDI-Format vor.
Das Spiel ruft in jedem Frame Funktionen im DULOG auf, um das Bild aus den verschiedenen Einzelbildern zusammen zu stellen. Es gibt ein nicht-transparentes Hintergrundbild, über das dann die diversen transparenten Bilder zusätzlich gelegt werden.
Dazu kommen sicher noch diverse Zusatzfunktionen, um das zugrundeliegende System zu abstrahieren, denn das DULOG wurde damals für verschiedene Systeme als Basis verwendet.
vielleicht kann ich etwas dazu sagen, da ich ab ca. 2007 sehr viel Zeit mit dem Analysieren von Biing2(A), Fate 2 und Dynatech 2 verbracht habe. So viel, daß ich später auch die Dateien sauber auslesen und modifizieren konnte, so daß ich nach Olafs Tod die verschiedenen Versionen noch eine zeitlang interessierten Spielern weiterhin personalisiert zur Verfügung stellen konnte. Anekdote: Der ursprüngliche Auslöser dafür war, daß Olaf in Fate2 die Startbildschirm-Grafik geändert hatte und ich aber die alte wieder haben wollte
Außerdem habe ich tonnenweise die Datenstrukturen in den Spielen analysiert und dekodiert. Zur Spiellogik kann man sagen, daß Olaf - nach eigener Aussage - sehr viel mit Zufall und Parametern gearbeitet hat, so daß er am Ende selbst nicht mehr wußte, was das Spiel tat. Denn er wollte seine Spiele auch selber spielen.
Er hat mir auch mal einen Teil vom Biing2-Sourcecode zukommen lassen (>1MB Assembler) - wie gesagt, nur ein Teil des Codes - weil ich ihm helfen sollte, seine Hilfstools zu modernisieren - leider war dies 2011 und es wurde nichts mehr daraus.
Und obwohl ich den Assemblercode problemlos lesen kann, kann ich sagen, daß es wirklich eher sinnvoller ist, ein Rework neu aufzubauen, als den Code (die EXE) zu disassemblieren.
Nun zu Deiner Frage: DULOG.
Das DULOG ist eine einfache GameEngine, die von Holger Gehrmann ebenfalls in Assembler erstellt und weiterentwickelt wurde. Das DULOG enthält den grundsätzlichen GameLoop, nimmt die Eingaben entgegen, baut die Grafikausgabe auf und gibt Sounds und Musik (eigener MIDI-Sequenzer) aus.
Die Daten sind in Archiv-Dateien zusammengefaßt - aber das weißt Du ja schon. Die Grafiken haben einen Header, der das Format beschreibt. Sie sind teilweiese auch transparent. Die WAV-Daten haben alle dasselbe Format (SamplingRate, Bits). Die Musik liegt in eigenen Dateien im MIDI-Format vor.
Das Spiel ruft in jedem Frame Funktionen im DULOG auf, um das Bild aus den verschiedenen Einzelbildern zusammen zu stellen. Es gibt ein nicht-transparentes Hintergrundbild, über das dann die diversen transparenten Bilder zusätzlich gelegt werden.
Dazu kommen sicher noch diverse Zusatzfunktionen, um das zugrundeliegende System zu abstrahieren, denn das DULOG wurde damals für verschiedene Systeme als Basis verwendet.
Re: Biing!/Dulog technische Dinge
Hallo,
vielen Dank für deine ausführliche Antwort. Dies deckt sich teilweise mit meinen Nachforschungen. Irgendwo dächte ich einmal vor Jahren gelesen zu haben, das DULOG auch eine Art Interpreter sei. Welcher den eigentlichen Spielcode, der in eine Art Assembler mit reduzierten OpCodes vermutlich, übersetzt. Genau nach diesen Bytecode hatte ich damals Ausschau gehalten und wäre ein Ansatz gewesen diesen zu nutzen. Liege ich damit richtig?
Ich bin gerade dabei zu eruieren in wie weit es sich lohnt dieses Projekt wieder aufzunehmen. Interesse verspüre ich, möchte aber auch so nah wie möglich am Original bleiben. Das Projekt war/ist schon ziemlich weit fortgeschritten. Die komplette Steuerung ist bereits implementiert. Durch die einzelnen Räume kann navigiert und auch interagiert werden. Was eben noch fehlt ist ein Großteil der Spielmechanik.
Ich habe einmal ein paar aktuelle Projekt Bilder angehängt. Leider gehen nur drei.
vielen Dank für deine ausführliche Antwort. Dies deckt sich teilweise mit meinen Nachforschungen. Irgendwo dächte ich einmal vor Jahren gelesen zu haben, das DULOG auch eine Art Interpreter sei. Welcher den eigentlichen Spielcode, der in eine Art Assembler mit reduzierten OpCodes vermutlich, übersetzt. Genau nach diesen Bytecode hatte ich damals Ausschau gehalten und wäre ein Ansatz gewesen diesen zu nutzen. Liege ich damit richtig?
Ich bin gerade dabei zu eruieren in wie weit es sich lohnt dieses Projekt wieder aufzunehmen. Interesse verspüre ich, möchte aber auch so nah wie möglich am Original bleiben. Das Projekt war/ist schon ziemlich weit fortgeschritten. Die komplette Steuerung ist bereits implementiert. Durch die einzelnen Räume kann navigiert und auch interagiert werden. Was eben noch fehlt ist ein Großteil der Spielmechanik.
Ich habe einmal ein paar aktuelle Projekt Bilder angehängt. Leider gehen nur drei.
- Personalbüro mit Stellenausschreibung (unfertig)
- Editor mit den einzelnen Bildschirmen
- Hauptbildschirm (Büro) im Spiel. Funktionsfähig
-
dragonling
- Hexer/Hexe
- Beiträge: 857
- Registriert: Mo 11.08.2003 - 05:50
- Wohnort: Hanau
- Kontaktdaten:
Re: Biing!/Dulog technische Dinge
Ob das DULOG auch ein Interpreter ist, kann ich nicht sagen. Ich weiß nicht, in welchen Spielen das System noch verwendet wurde.
Der Sourcecode-Auszug von Biing2, den ich bekommen habe, ist jedenfalls x86-Assembler-Code durchzogen mit unzähligen Macros, die ebenfalls, soweit in diesen Dateien definiert, aus x86-Assembler bestehen.
Meine Vermutung ist, daß Olaf das Dulog als Plattform für I/O genutzt, aber die Spiele ansonsten unabhängig komplett in Assembler selbst geschrieben hat. Es ist also gut möglich, daß er bei weitem nicht alle Funktionen von Dulog genutzt hat.
Das bestätigt sich im Grunde durch die am Anfang des Sourcecode aufgelisteten "EXTRN C"-Definitionen:
Der Source-Code-Auszug, den ich habe, sind insgesamt 6MB mit über 300.000 Zeilen Code und Daten, und ehrlich: Nach Durchsicht wollte ich den wirklich nicht analysieren. Zumal ich relativ sicher bin, nicht mal allen Sourcecode zu haben. Die beiden Dateien sehen jedenfalls danach aus, daß noch Sachen fehlen. Und mit "ein paar Stunden im Monat" wäre es selbst für diese beiden Dateien schon ein Projekt für Jahre, da durchzusteigen.
Du redest allerdings von Biing1, womit ich mich kaum beschäftigt habe, allerdings glaube ich, daß es im Grunde keinen Unterschied zum Nachfolger gibt, was die Art und Weise der Progrmamierung betrifft, nur das das Dulog sich dazwischen etwas weiter entwickelt hat.
Der Sourcecode-Auszug von Biing2, den ich bekommen habe, ist jedenfalls x86-Assembler-Code durchzogen mit unzähligen Macros, die ebenfalls, soweit in diesen Dateien definiert, aus x86-Assembler bestehen.
Meine Vermutung ist, daß Olaf das Dulog als Plattform für I/O genutzt, aber die Spiele ansonsten unabhängig komplett in Assembler selbst geschrieben hat. Es ist also gut möglich, daß er bei weitem nicht alle Funktionen von Dulog genutzt hat.
Das bestätigt sich im Grunde durch die am Anfang des Sourcecode aufgelisteten "EXTRN C"-Definitionen:
Code: Alles auswählen
EXTRN C cShowIcon:PROC ;icon-num, xoff, yoff, layer
EXTRN C cShowHighlight:PROC ;icon-num, xoff, yoff, textnum, layer
EXTRN C cShowHighText:PROC ;icon-num, xoff, yoff, textnum, layer
EXTRN C cSetMenue:PROC ;menue-num
EXTRN C cScanTxtOut:PROC ;x,y,text,size,font
EXTRN C cLeftTxtOut:PROC ;x,y,text,size,font
EXTRN C cRightTxtOut:PROC ;x,y,text,size,font
EXTRN C cCenterTxtOut:PROC ;x,y,text,size,font
EXTRN C cBlockTxtOut:PROC ;x,y,text,size,font
EXTRN C cClrScreen:PROC ;
EXTRN C cAllocMem:PROC ;mempoint,length
EXTRN C cFreeMem:PROC ;mempoint
EXTRN C cLoadFile:PROC ;filename,mempoint,length
EXTRN C cOpenFile:PROC ;filename
EXTRN C cReadFile:PROC ;address,length
EXTRN C cCloseFile:PROC ;
EXTRN C cOpenGameFile:PROC ;filename,groesse,cancel,end
EXTRN C cCreateGameFile:PROC ;filename,groesse,cancel,end
EXTRN C cReadGameFile:PROC ;address,length
EXTRN C cCloseGameFile:PROC ;
EXTRN C cWriteGameFile:PROC ;Adr,Length
EXTRN C cGetRandom:PROC ;randomvalpoint
EXTRN C cClearLayer:PROC ;dword layer
EXTRN C cCreateWeather:PROC ;Hell,Nebel,Regenst,Regenri
EXTRN C cCreateFile:PROC ;Filename
EXTRN C cWriteFile:PROC ;Adr,Length
EXTRN C cCloseFile:PROC
EXTRN C cDestroy:PROC
EXTRN C cErrorOut:PROC ;dd
EXTRN C cSetZab:PROC ;Zeilenabstand
EXTRN C cBlockClipTxtOut:PROC ;x,y,text,size,font,schatten,ystart,yend,xstart,breite
EXTRN C cScanClipTxtOut:PROC ;x,y,text,size,font,schatten,ystart,yend,xstart,breite
EXTRN C cZoomIcon:PROC ;icon,xoff,yoff,xout,yout,swflag
EXTRN C cSetCharColor:PROC ;rot.l,grün.l,blau.l
EXTRN C cPlaySounds:PROC ;Pointer
EXTRN C cPlayAdvancedSound:PROC ;nr,channel,volume,panning,loop,pointer
EXTRN C SoundPlaying:DWORD
EXTRN C cPlayMidiFile:PROC ;ptr auf name end 0
EXTRN C cStopMidiFile:PROC
EXTRN C Midiflag:DWORD
EXTRN C cIxy:PROC ;ptr auf 4 words, iconnr
EXTRN C cGetLocalTime:PROC ;ptr auf 8 words
EXTRN C cCheckKey:PROC ;2 ptr auf dword
EXTRN C cSetSpeed:PROC ;dword
Du redest allerdings von Biing1, womit ich mich kaum beschäftigt habe, allerdings glaube ich, daß es im Grunde keinen Unterschied zum Nachfolger gibt, was die Art und Weise der Progrmamierung betrifft, nur das das Dulog sich dazwischen etwas weiter entwickelt hat.
Re: Biing!/Dulog technische Dinge
Nun, Biing! lief unter Amiga/DOS während Biing 2 für Windows 9x (??) war. Unter Windows musste man die API benutzten für I/O Aufgaben unter DOS waren es da die Interrupts.
Leider gestaltet sich das Analysieren der BIPRO Binary schwierig, da es kaum noch Tools für DOS 16/32bit Programme gibt. Auch, kam das Spiel zu einer Zeit auf den Markt wo es ein Wildwuchs an DOS Extender für den Protected Mode, Stichpunkt DPMI/VCPI, gab. Dieser ist bei Biing! für mich immer noch unbekannt und so auch schwierig mit IDA/Ghidra zu analysieren. Aus dem Grund habe ich es mit einem CPU TRACE LOG aus DosBox probiert. Dieser generierte mir aber eine 3.5 GB Größe Datei für ein paar Sekunden der Ausführung. Zum Analysieren gibt es da auch keine Tools, was dies erheblich erleichtern würde. Ich bastle gerade an einem 16/32bit Disassembler, welcher mir mithilfe des CPU TRACE LOGS eine Art Heatmap der Binary erstellt. So kann ich Code von Daten in der Binary sauber trennen und kann feststellen, ob es wirklich eine Art Interpreter Code gibt. Leider frisst dies auch schon Zeit und ich greife schon auf den Source Code von DOSBOX zurück.
Mir ist vollkommen bewusst, dass eine Disassemblierung bzw. die Interpretation des Codes Monate, wenn nicht Jahre dauern würde. Ich möchte auch nicht den gesamten Code analysieren, mir reicht es schon Informationen über bestimmte Dinge zu erlangen. Die ich in Dateien nicht finden konnte. z.B. Die Positionierung der Texte bei den Datenblättern, Krankheitsverläufe mit Behandlungsfortschritt, allgemeine Berechnungen zu Werten usw. Irgendwie kann ich nicht glauben das dieses hart als Code geschrieben wurde, für jede Krankheit.
Leider gestaltet sich das Analysieren der BIPRO Binary schwierig, da es kaum noch Tools für DOS 16/32bit Programme gibt. Auch, kam das Spiel zu einer Zeit auf den Markt wo es ein Wildwuchs an DOS Extender für den Protected Mode, Stichpunkt DPMI/VCPI, gab. Dieser ist bei Biing! für mich immer noch unbekannt und so auch schwierig mit IDA/Ghidra zu analysieren. Aus dem Grund habe ich es mit einem CPU TRACE LOG aus DosBox probiert. Dieser generierte mir aber eine 3.5 GB Größe Datei für ein paar Sekunden der Ausführung. Zum Analysieren gibt es da auch keine Tools, was dies erheblich erleichtern würde. Ich bastle gerade an einem 16/32bit Disassembler, welcher mir mithilfe des CPU TRACE LOGS eine Art Heatmap der Binary erstellt. So kann ich Code von Daten in der Binary sauber trennen und kann feststellen, ob es wirklich eine Art Interpreter Code gibt. Leider frisst dies auch schon Zeit und ich greife schon auf den Source Code von DOSBOX zurück.
Mir ist vollkommen bewusst, dass eine Disassemblierung bzw. die Interpretation des Codes Monate, wenn nicht Jahre dauern würde. Ich möchte auch nicht den gesamten Code analysieren, mir reicht es schon Informationen über bestimmte Dinge zu erlangen. Die ich in Dateien nicht finden konnte. z.B. Die Positionierung der Texte bei den Datenblättern, Krankheitsverläufe mit Behandlungsfortschritt, allgemeine Berechnungen zu Werten usw. Irgendwie kann ich nicht glauben das dieses hart als Code geschrieben wurde, für jede Krankheit.
-
dragonling
- Hexer/Hexe
- Beiträge: 857
- Registriert: Mo 11.08.2003 - 05:50
- Wohnort: Hanau
- Kontaktdaten:
Re: Biing!/Dulog technische Dinge
Ich habe mal kurz über die BIPRO.EXE geschaut. (ich habe noch die originale Disketten-Version, allerdings mit einem später erschienenen Patch und der Möglichkeit, die Einzeldateien zu den Block-Dateien zusammenzufassen)
Was man direkt sagen kann ist, daß DPMI genutzt wird, was heißt, daß auf den entsprechenden Treiber (müßte EMM386.sys sein) zugegriffen wird. Der wurde, wenn ich mich richtig erinnere, über die Interrupt-Funktionen angesprochen. Ich selbst habe den damals aber nicht in meinen Programmen genutzt. Auf jeden Fall findet man Fehlertexte in der EXE die sich auf DPMI beziehen. Eine kleine Recherche sollte reichen, um die INT-Funktionscodes vom DPMI-Treiber zu finden. Dann kann man die entsprechenden INT-Aufrufe im disassemblierten Code passend markieren.
Auf jeden Fall hat das Dulog für Olaf die Low-Level-API Zugriffe, egal ob DOS oder Windows, abstrahiert. Deswegen war er auch immer auf Holger angewiesen, wenn er eine neue Funktion brauchte, damit Holger sie ihm im Dulog bereitstellt.
Weiterhin findet man in der EXE diverse Strukturen, Daten und Texte fest in der EXE. Die hast Du sicher aber auch schon gefunden.
Ja, Olaf hat - auch in späteren Spielen - feste Daten oft direkt in strukturierten Tabellen direkt im Sourcecode, und damit in der Exe, hinterlegt. Es waren nur wenige Arten von Daten, die in separaten Dateien liegen und nachgeladen werden. Er hat damals nicht, so wie heute üblich, komplett data-driven programmiert, sondern die Logik war komplett im Sourcode. Deswegen haben seine Daten so viele Parameter, die in komplizierten Berechnungen miteinander verwursted werden. Und deswegen mußte er auch immer wieder, wenn sich Daten oder Logik verändert haben, die Exe neu kompilieren.
Du mußt bedenken, daß er immer in Assembler programmiert hat, und das zu Zeiten, wo Text-Editor + MASM oder TASM auf dem PC dafür Stand der Technik waren. Heute gibt es IDEs, in denen man sogar strukturiert und ansatzweise objektorientiert Assembler schreiben kann. Wenn ich mich recht erinnere sagte er auch mal, daß er einen modifizierten und angepaßten MASM verwendet.
Als ich vor 10-15 Jahren rumgeforscht habe, habe ich hauptsächlich den "Artmoney" genutzt, um den Speicher während des Spiels zu beobachten, und ich habe mit einem Debugger zur Laufzeit die Routinen rausgesucht, die die Dateien laden und vor allem dekodieren. Allerdings war das einfacher, da die Dateien recht früh im Ablauf geladen werden.
Du suchst aber nach den Berechnungen, die im Gameloop erfolgen. Diesen müßte man finden, dann könnte man davon ausgehend evtl. weiter kommen. Aber schön wird das nicht.
Was die "Positionierung von Text" betrifft: Das Dulog bietet Funktionen, Textausgabe zu positionieren. Und die die nutzbaren Auflösungen durch das Dulog vorgegben waren, war es auch recht einfach die Positionierung für die Texte im Krankenblatt fest im Code zu hinterlegen.
Was man direkt sagen kann ist, daß DPMI genutzt wird, was heißt, daß auf den entsprechenden Treiber (müßte EMM386.sys sein) zugegriffen wird. Der wurde, wenn ich mich richtig erinnere, über die Interrupt-Funktionen angesprochen. Ich selbst habe den damals aber nicht in meinen Programmen genutzt. Auf jeden Fall findet man Fehlertexte in der EXE die sich auf DPMI beziehen. Eine kleine Recherche sollte reichen, um die INT-Funktionscodes vom DPMI-Treiber zu finden. Dann kann man die entsprechenden INT-Aufrufe im disassemblierten Code passend markieren.
Auf jeden Fall hat das Dulog für Olaf die Low-Level-API Zugriffe, egal ob DOS oder Windows, abstrahiert. Deswegen war er auch immer auf Holger angewiesen, wenn er eine neue Funktion brauchte, damit Holger sie ihm im Dulog bereitstellt.
Weiterhin findet man in der EXE diverse Strukturen, Daten und Texte fest in der EXE. Die hast Du sicher aber auch schon gefunden.
Ja, Olaf hat - auch in späteren Spielen - feste Daten oft direkt in strukturierten Tabellen direkt im Sourcecode, und damit in der Exe, hinterlegt. Es waren nur wenige Arten von Daten, die in separaten Dateien liegen und nachgeladen werden. Er hat damals nicht, so wie heute üblich, komplett data-driven programmiert, sondern die Logik war komplett im Sourcode. Deswegen haben seine Daten so viele Parameter, die in komplizierten Berechnungen miteinander verwursted werden. Und deswegen mußte er auch immer wieder, wenn sich Daten oder Logik verändert haben, die Exe neu kompilieren.
Du mußt bedenken, daß er immer in Assembler programmiert hat, und das zu Zeiten, wo Text-Editor + MASM oder TASM auf dem PC dafür Stand der Technik waren. Heute gibt es IDEs, in denen man sogar strukturiert und ansatzweise objektorientiert Assembler schreiben kann. Wenn ich mich recht erinnere sagte er auch mal, daß er einen modifizierten und angepaßten MASM verwendet.
Als ich vor 10-15 Jahren rumgeforscht habe, habe ich hauptsächlich den "Artmoney" genutzt, um den Speicher während des Spiels zu beobachten, und ich habe mit einem Debugger zur Laufzeit die Routinen rausgesucht, die die Dateien laden und vor allem dekodieren. Allerdings war das einfacher, da die Dateien recht früh im Ablauf geladen werden.
Du suchst aber nach den Berechnungen, die im Gameloop erfolgen. Diesen müßte man finden, dann könnte man davon ausgehend evtl. weiter kommen. Aber schön wird das nicht.
Was die "Positionierung von Text" betrifft: Das Dulog bietet Funktionen, Textausgabe zu positionieren. Und die die nutzbaren Auflösungen durch das Dulog vorgegben waren, war es auch recht einfach die Positionierung für die Texte im Krankenblatt fest im Code zu hinterlegen.
Re: Biing!/Dulog technische Dinge
Ich habe von Biing! (eine der ersten) CD Versionen, leider auch mit dem fehlerhaften Handbuch mit welchem man nicht die Passwortabfrage meistern konnte. Zum Glück habe ich damals irgendwo dann doch den Patch noch gefunden.
Genau, disassemblieren konnte ich bis zum Eintritt in den Protected Mode dann gaben die (heute) gängigen Tools IDA/Ghidra/etc. auf. Nachträglich dieses aufzulösen brachte diese dann durcheinander, auch sind meine Kenntnisse da auch nicht wirklich ausgeprägt.
Um Texte zu positionieren habe ich damals mit Screenshots aus DOSBOX gearbeitet. So konnte ich einigermaßen Text an die richtige X/Y Position bringen. Jedoch nur solche, wo ich ein Beispiel hatte. Was ziemlich ätzend war und die Motivation ziemlich killt. Auch fehlen mir noch wirklich Schlüsselereignisse wie das Krankenwagenrenner. So weit war ich im Spiel noch nie.
Hm, ich werde erst einmal mit der Heatmap weitermachen, vielleicht stoße ich da auf etwas.
Genau, disassemblieren konnte ich bis zum Eintritt in den Protected Mode dann gaben die (heute) gängigen Tools IDA/Ghidra/etc. auf. Nachträglich dieses aufzulösen brachte diese dann durcheinander, auch sind meine Kenntnisse da auch nicht wirklich ausgeprägt.
Um Texte zu positionieren habe ich damals mit Screenshots aus DOSBOX gearbeitet. So konnte ich einigermaßen Text an die richtige X/Y Position bringen. Jedoch nur solche, wo ich ein Beispiel hatte. Was ziemlich ätzend war und die Motivation ziemlich killt. Auch fehlen mir noch wirklich Schlüsselereignisse wie das Krankenwagenrenner. So weit war ich im Spiel noch nie.
Hm, ich werde erst einmal mit der Heatmap weitermachen, vielleicht stoße ich da auf etwas.
