Reverse Engineering der NLT II

[Shihan]

Ja, genauso sieht es heute auch noch aus. Aber moderne größere Spiele haben nicht nur einen Thread, sondern mehrere. Also einen für Graphik, einen für die eigentliche Applikation. Manchmal noch welche für Netzwerk und Physikberechnungen. Das verteilt die Arbeit dann.

Und auf modernen CPUs mit mehreren Kernen, egal ob physikalisch oder logisch, ist im Normalfall immer irgendwo Luft.
Dafür sorgt das Betriebssystem bzw. dessen Scheduler, der die Threads ganz gerne mal hin und her verschiebt, wie es gerade am Besten passt.

Da hier aber immer das Betriebssystem die Hardware kontrolliert, kann ein Prozess gar nicht mehr alles an sich reißen.
Und solange die CPU mehr Kerne hat als das Spiel an Threads aufmacht, können auch andere Prozesse drankommen. Die gesamte Situation ist also deutlich anders als damals unter DOS.

[Hirukan]

Ja natürlich. Das hat DOS nicht gemacht. Aber ganz ehrlich gesagt hat es das auch nicht gebraucht. Da wurde ja das Programm gestartet und es war ja auch das Einzige das dann auch wirklich (bis auf Treiber, etc...) gelaufen ist. Und es gab ja auch keine Möglichkeit zwischen Programmen hin und her zu schalten. (Ich war noch ein Kind zu DOS Zeiten, aber zumindest habe ich keine Möglichkeit gesehen da hin und her zu schalten). Also war das ja so in Ordnung. Ich meine mich zu erinnern, dass DOS ja eine Weiterentwicklung von QDOS war (Quick and Dirty Operating System), bevor es MS-DOS wurde (ob es dann nicht noch mehr dirty wurde hmmm).

Jedenfalls hab ich großen Respekt von der Reverse Engineering was mit schick_cc gemacht wird. Ich weiß nicht ob ich die Geduld und die Fähigkeit hätte das selbst zu machen. Und möchte mich bei allen Beteiligten dafür bedanken. Ich freue mich darauf es testen zu dürfen und meinen Kleinigkeit mit der AppImage dann beizutragen wenn es denn dann fertig ist.

[HenneNWH]

Zwischenstand:

Code:

# host_read   : 170
# host_write  : 0
BAE CODE      : 61
BAE OVR       : 1854

[llm]

Hmm was ich meinte. Im Grunde schaut ja ein Spiel (natürlich ganz vereinfacht dargestellt) heute ja auch noch so aus oder?

Code:

while(running)
{
    process_input();
    update();
    draw();
}

Also was qualitativ in der Endlosschleife passiert hängt ja ganz vom Spiel und der Idee ab   
Aber im Grunde wenn man dem Prozessor keine Luft gibt (am Ende der Schleife ein sleep einbaut, das die Framerate drosselt oder es halt vom Grafikkarten Treiber und vsync machen lässt), dann egal wie "primitiv" das Spiel ist, es haut raus was die Hardware mitmacht oder?

nein - damit bringst du maximal einen Core auf 100% (unter der annahme das dein Code nicht APIs aufruf die vom Betriebssystem schon parallel verarbeitet werden), aber deine anderen schlafen mehr oder minder, skalierbarkeit über Cores muss explizit in Form von multi-threading(eher typisch) oder multi-processing(wie bei Chrome - jeder Tab ein Prozess) eingebaut werden

[Hirukan]

nein - damit bringst du maximal einen Core auf 100% (unter der annahme das dein Code nicht APIs aufruf die vom Betriebssystem schon parallel verarbeitet werden), aber deine anderen schlafen mehr oder minder, skalierbarkeit über Cores muss explizit in Form von multi-threading(eher typisch) oder multi-processing(wie bei Chrome - jeder Tab ein Prozess) eingebaut werden

Ja schon. Das wäre der Hauptthread der je nach Bedarf andere Threads startet die dann möglicherweise vom OS auf anderen Kernen ausgeführt werden.

Aber auch diese eine Endlosschleife (selbst wenn sie wirklich nichts macht) wäre genug um auch den Prozessor ganz schön heiß laufen zu lassen, da ja wie gesagt ein Kern auf 100 % arbeitet. Aber das ist ja alles noch ein wenig komplizierter da 100 % mit bestimmt Operationen mehr Watt ziehen und somit mehr Wärme entwickeln als eventuell eine "leere" Schleife.

Aber auch bei Spielen ist es relativ "neu" dass Anwendungen auf mehreren Threads gleichzeitig gerendert werden können. So weit ich weiß ist das erst mit Vulkan und D3D12 vernünftig möglich. OpenGL hat da ja einige Probleme damit. Aber ja zumindest Laden von Daten, eventuell Physik, Netzwerk, ... waren auf andere Threads ausgelagert, was bei vielen Spielen aber immer noch so wäre, dass ein Thread weitaus mehr zu tun hatte als Andere. Aber wie genau die Arbeitsverteilung bei einer Vulkan Anwendung aussieht weiß ich nicht, da ich mich mir Vulkan einfach zu wenig auseinandergesetzt habe. Ich kann mir vorstellen dass auch bei den modernsten Anwendungen ein Thread durchaus mehr macht als die anderen.

Um einen Prozessor ganz auszulasten, das wird ja eigentlich nur in synthetischen Benchmarks gemacht.

[Hirukan]

Aber was mein ursprünglicher Post aussagen sollte ist,

dass auch moderne Spiele so programmiert sind als wären sie die einzige Anwendung die Läuft. Nur ist hier nun ein besseres OS, das sich um die Arbeitsverteilung kümmert als zu DOS Zeiten.
Wenn mein Beispiel auf einem modernen Rechner in einer DOS-Umgebung kompiliert und ausgeführt wird, dann ist ein Kern des Prozessors ganz ausgelastet, was dazu führen würde, dass das ganze System ausgelastet ist, da DOS ja von multicore keine Ahnung hat.

Aber genug ausgeholt

[llm]

Aber was mein ursprünglicher Post aussagen sollte ist,

dass auch moderne Spiele so programmiert sind als wären sie die einzige Anwendung die Läuft. Nur ist hier nun ein besseres OS, das sich um die Arbeitsverteilung kümmert als zu DOS Zeiten.
Wenn mein Beispiel auf einem modernen Rechner in einer DOS-Umgebung kompiliert und ausgeführt wird, dann ist ein Kern des Prozessors ganz ausgelastet, was dazu führen würde, dass das ganze System ausgelastet ist, da DOS ja von multicore keine Ahnung hat.

Aber genug ausgeholt

bei DOS hat man sich einfach immer tod "gepollt" - das hat auch mit Kernen nichts zu tun - eher das "intelligentere warten" was moderne OSes heute bieten ist da entscheident
- anstatt ständig zu fragen ob was passiert ist reagiert man erst wenn was passiert ist...

[Hirukan]

bei DOS hat man sich einfach immer tod "gepollt" - das hat auch mit Kernen nichts zu tun - eher das "intelligentere warten" was moderne OSes heute bieten ist da entscheident
- anstatt ständig zu fragen ob was passiert ist reagiert man erst wenn was passiert ist...

Die meisten Spiele rendern doch auch, wenn nichts geklickt wird, oder Taste gedrückt wird. Dann wird halt die idle Animation abgespielt, die Gegner rennen immer noch herum, .... Aber ja je nach Software ist es Event gesteuert, aber ein Spiel hat für gewöhnlich auch bei keiner Momentanen Eingabe zu tun.

Edit: Das wäre doch auch witzig wenn eine conditional Variable blocken würde und auf Input wartet

[Obi-Wahn]

Passend zum Thema:

Heise c't: BioForge & Diablo: Reverse Engineering bringt alte Spiele in neuem Glanz zurück

[Shihan]

@Obi-Wahn: Geht's da um Devilution, wenn von Diablo gesprochen wird? Ist leider hinter einer Paywall und anscheinend lohnt es sich für deutsche Verlage nicht, Einzelkäufe für Artikel anzubieten...


@Ilm, Hirukan:
Die Wahrheit liegt mittlerweile irgendwo dazwischen. Es wird nicht zwangsläufig totgepollt, aber auch nicht soviel Gas wie möglich beim Rendern gegeben.
Für das Rendern gibt es mittlerweile sehr oft die äußere Regulation über vsync. Es wird nur soviel gerendert, wie notwendig ist, um die Ziel-Framerate zu erhalten. Danach fügt der GPU-Treiber automatische Barriers ein, um keine unnötige Arbeit zu machen. Wie sleep bei CPU-basierten Teilen.

Und auch wenn es natürlich einige OS-Events gibt, auf die eine Applikation ansprechen kann, ist es bei Spielen insbesondere bei Tastatur & Maus oft so, dass der aktuelle Status gelesen und dann intern weiterverarbeitet wird. Da existiert dann nicht zwangsläufig ein Event-Handler, der auf einen Tastendruck reagiert. Es wird dann eher in einem sehr kurzen, nicht-blockierenden Aufruf sowas wie "Ist-Mausbutton-links-gedrückt" geprüft und dann in einer internen Map eingetragen, damit der Rest der Applikation angemessen reagieren kann.
Hat damit zu tun, dass man die OS-Events und -Interaktion oft ganz gerne komplett wegkapselt (was wiederrum viele andere Vorteile bietet).

Wie gesagt, Mischform.


@Crystal & einen anderen hilfreichen Menschen mit der notwendigen Berechtigung:
Möchtet ihr / könnt ihr die letzten Beiträge über Technik, die nicht NLT-spezifisch sind, ggf. hier abteilen und an eine andere Stelle bringen? Thematisch nicht uninteressant, aber auch nichts, was ganz direkt mit dem Reverse Engineering der NLT zu tun hat

[HenneNWH]

Zwischenstand: Schick nimmt weiter Gestalt an.
Es existieren noch genau 2 Funktionen, bei denen der BCC an einigen Stellen anderen Code erzeugt.
Die Funktionen sind: seg048:status_menu() und seg106:pass_item().

Weiterhin sind die Relokationsadressen im EXE-Header noch nicht in der richtigen Reihenfolge.
Das sollte sich mit Variablen umsortieren und dem Ändern der Linkreihenfolge ändern lassen.

Code:

# host_read   : 22
# host_write  : 0
BAE CODE      : 49
BAE OVR       : 320

[llm]

Zwischenstand: Schick nimmt weiter Gestalt an.
Es existieren noch genau 2 Funktionen, bei denen der BCC an einigen Stellen anderen Code erzeugt.
Die Funktionen sind: seg048:status_menu() und seg106:pass_item().

Weiterhin sind die Relokationsadressen im EXE-Header noch nicht in der richtigen Reihenfolge.
Das sollte sich mit Variablen umsortieren und dem Ändern der Linkreihenfolge ändern lassen.

Code:

# host_read  : 22
# host_write  : 0
BAE CODE      : 49
BAE OVR      : 320

Sehr schön - die Gestalt nimmt nicht nur Form an - die wandelt ja bald

[HenneNWH]

Das bleibt zu hoffen: ich bleib dran!

"Das Fundament ist die Basis der Grundlage!"

[HenneNWH]

Sooo, die sehr technischen Dinge sind behoben.
Zur Erklärung: Die 319 Byte Differenz im Overlay Code sind sehr wahrscheinlich der Grund für die 25 Byte Differenz im unausgelagerten Code.

Die erzeugte BLADEM.EXE hab ich in der DOSBox schon probiert und (natürlich) bleibt die DOSBox beim Übergeben von Gegenständen hängen.

Bin selbst gespannt, ob ich die beiden Funktionen noch zurechtgebogen bekomme.

Code:

BAE CODE = 25
BAE OVR = 319