letzter Beitrag von DATA-LAND am
Da zählt jeder Zyklus
Verstehe - hatte schon gar nicht mehr dran gedacht, dass manche ja gar keine externe Beschleunigerhardware haben. 
Und diejenigen kommen ja sowieso nicht auf die 8 Bilder pro Frame.
Es sind halt die damaligen Protzmodelle
Stimmt, aber kennst du oder andere irgendeinen Vorzug/Unterschied außer der Optik? Manchmal ist es auch so, dass man ein Auto nach Geswchmack wählt, aber alle Modelle gleich schnell sind.
Aber wenn Du die auch hier postest, könnte natürlich jeder vergleichen.
Wird gemacht. Eine neue Betaversion ist angehängt. Wäre nett, wenn jemand mal die Originalversion mit der gepatchten auf einem normalen C64 (ohne Beschleunigung) vergleichen und sagen könnte, ob man überhaupt einen Unterschied in der Graphik bemerkt (auch bezüglich der Geschwindigkeit).
- Ich chabe vor, morgen (SA) mit Exploding First nochmal intensiv TD I & II zu spielen - bei 20 MHz. Dazu möchte ich auch vom 2. Teil ein Video machen und es hier veröffentlichen. Mir geht es dabei als Veranschaulichung zum Vergleich mit einem TC64.
Viel Spaß dabei! Für das Video würde ich die ersten beiden Levels der neuen Betaversion empfehlen, da sich dort der Patch am meisten auswirken würde. Ein großer Nachteil bei TD II besteht darin, daß das Programm in teils redundante Module aufgespalten ist, von denen ich mit Ausnahme des Hauptgraphikmoduls nur die Originalfahrt (Master) und davon insbesondere den ersten Level gepatcht habe. (Genauer gesagt betrifft dies die Routine zum Malen der Hintergrundgraphik.) Im dritten Level fehlt diese Optimierung bereits, da das Modul für den Level die gleiche Routine noch einmal mitbringt. Des weiteren sind Optimierungen zur Fahrtberechnung nur im Modul für die Master-Fahrstrecke enthalten. Die beiden anderen Fahrstrecken enthalten vergleichbaren Code, müßten aber getrennt gepatcht werden. Aus diesem Grunde handelt es sich auch nur um eine Beta-(= unvollständige) Version.
alles weitere Experimentieren wäre dann quasi freiwllig wie du eben motiviert bist...
Das Experimentieren ist bereits abgeschlossen. Die wichtigsten Graphikroutinen etc sind schon abgeändert. Es käme nur noch darauf an, einige Veränderungen auch in den anderen Modulen vorzunehmen, sofern der Aufwand wirklich lohnt.
Vielleicht könnte man das Risiko aber minimieren, in dem man nicht einzelne Stellen fixt, sondern - so wie du es auch mit den Kakteen gemacht hast - ganze Abschnitte austauscht.
Genau so bin ich auch größtenteils vorgegangen. Die Multiplikationsroutine betrifft solch einen Abschnittaustausch. Die nächst größere Kategorie wäre die gesamte Straßenberechnung, die sich schwerlich austauschen läßt.
ielleicht könnten auch Tabellen noch einzelne Abschnitte beschleunigen!?
Leider nein. Für größere Tabellen ist kein Platz mehr im Code. Zwar konnten hier und da einige Bytes eingespart werden, doch ist es nicht möglich das Programm zusammenzustauchen, um so die frei gewordenen Bytes an einer Stelle anzusammeln, da verschiedene Module von außen direkt in den Code springen, was den Code nicht relokatibel macht. Und das, obwohl der Programmierer für solche externen Einsprünge extra eine Sprungtabelle angelegt hat. Er hat sie nur nicht konsequent verwendet.
[...]
Also habe ich die fehlerhafte Multiplikation ausgetauscht gegen die klassische Multiplikation, aber das Ergebnis war dann etwas... merkwürdig, zu sehen auf den folgenden Bildern (links Original, rechts Patch):
Wenn man genau hinsieht, erkennt man, daß der Seitenstreifen nicht ganz bis zum rechten Rand reicht. Dieser Effekt macht sich allerdings nur bemerkbar bei der Anfangsposition. Sobald man bei der Fahrt die Lenkung bewegt, verschwindet die Lücke. Es liegt wohl gemerkt nicht an einem Fehler der neuen Routine (tatsächlich ist das rechte Bild das richtig berechnete), sondern an der mangelhaften Berechnung im Original. Daher meine (zugegebenermaßen etwas ungewöhnliche) Frage: Soll trotz dieses Unterschieds in der Finalversion die korrigierte, richtig rechnende (und schnellere) Multiplikation eingebaut oder die alte weiter verwendet werden?
Wenn ich mir die beiden Fotos anschaue, so ist auf der rechten Seite ein Baum zu sehen der auf dem linken Foto weiter links steht.
Hat das was mit dem Patch zu tun oder hängt das an was völlig anderem?
Genauer gesagt, sind auf dem linken Foto sogar zwei Bäume zu sehen, während auf dem rechterem nur eine zu sehen ist.
Hat das was mit dem Patch zu tun oder hängt das an was völlig anderem?
Das liegt daran, daß das Spiel die Positionen der Zusatzelemente (Kakteen, Palmen, Steine etc) nicht fest speichert, sondern bei jeder Fahrt neu zufällig generiert. Da die Bilder zwei verschiedene Fahrten darstellen, war der Unterschied leider nicht vermeidbar. (Für komplett identische Bilder hätte ich tief in die Zufallsgeneration eingreifen müssen.)
Ok, alles klar und besten Dank für die Erklärung.
Guten Morgen zusammen,
hier nun die angekündigten Videos zum Vergleichen. Der Hinweis mit der neuen Betaversion kam allerdings zu spät - wir verwendeten die Version aus Post #71. (Werde die neue Version morgen Abend testen...)
Es geht mir dabei um zwei Punkte:
- Kann man vom optischen Eindruck sagen, dass M.J.s Patch bei der Fahrgeschwindigkeit in etwa gleich schnell ist - egal ob SuperCPU oder TC 64 verwendet wird?
- Ist auch der Lenkvorgang/Lenkbewegung in etwa gleich schnell?
Video #2 soll hier die Referenz sein. Es zeigt mich, wie ich überwiegend mit dem Porsche 959 im 4. Gang fahre. Ab der 26. Sekunde mache ich bewusst mehrere hektische Lenkradbewegungen, die in dieser schnellen Abfolge niemals mit 1 MHz zu realisieren wären. Also bitte mal auf die Randbepflanzung bzgl. Fahrgeschwindigkeit achten und auch mal zwischendurch am Lenkrad "rütteln". Ist beides auf dem TC 64 in etwa gleich flüssig?
Video #3 zeigt Exploding First bei etwa 350 km/h allerdings mit Automatik. Ich meine keine Steigerung mehr bzgl. Bildaufbau festzustellen, obwohl ich im Schnitt nur 200 km/h gefahren bin. Wahrscheinlich hatten wir beide schon diese magischen 8 Bilder pro Frame ausgereizt!?
Video #4 beinhaltet das Martinshorn der Polizei.
Video #1 (TD I) kann nochmal zum Vergleich mit #2 des Bildaufbaus herangezogen werden, da ich meine der 1. Teil läuft etwas schneller.
Okay, nun noch ein Gedankenspiel für ALLE - also auch für die, die über KEINEN "Turbo-Gang" verfügen:
Wenn man Schaltgetriebe wählt (ab Schwierigkeitsgrad 5) kann man gut im roten Drehzahlbereich fahren, was wiederum bedeutet, dass die Lenkung sofort und sehr wirkungsvoll reagiert. Auch ist dann der Bildaufbau natürlich sehr flüssig. Uns ist gestern aber mehrfach sehr ungangenehm aufgefallen, dass wenn man eine entsprechende Lenkbewegung macht, man ZWANGSWEISE an Geschwindigkeit verliert - gilt auch für Automatik! Und das z.T. so stark, dass man mehrere Gänge runterschalten muss. 
Das ist nicht nur unrealistisch, sondern bringt einen auch in große Bedrängnis, wenn Gegenverkehr kommt. Untertouriges Fahren erlaubt nur noch ein sehr schwerfälliges Lenken! Im originalen 1 MHz Modus kommt dann zum "torkelnden Fahrstil" noch eine zusätzliche Trägheit dazu! Bei TD I hat die Lenkbewegung KEINEN Einfluss auf die Fahrgeschwindigkeit, bzw. auf das Gaspedal!
Was meint ihr - angenommen M.J. könnte dieses ZWANGSWEISE Abbremsen nach einer Lenkbewegung unterbinden - wäre das euch lieber, bzw. würdet ihr einen zusätzlichen Trainer bevorzugen???
Wünsch euch noch einen schönen Muttertag und macht was aus dem herrlichen "Test Drive II Wetter"! 
https://drive.google.com/file/…kVJQTA/view?usp=drive_web
https://drive.google.com/file/…mRqREE/view?usp=drive_web
https://drive.google.com/file/…TFUSm8/view?usp=drive_web
Ich bin mal gerade zwei Strecken gefahren. Mit der optimierten Multiplikation sind es aber nicht nur die paar Pixel, die in der Startposition fehlen. Während der gesamten Fahrt treten da am rechten Rand Verzerrungen auf. Es ist wohl besser, den Rechenfehler beizubehalten, da offenbar die ganze Routine darauf ausgelegt ist.
Diesmal habe ich keine Punkte am Himmel aufblitzen sehen. Kann natürlich Zufall sein.
Was meint ihr - angenommen M.J. könnte dieses ZWANGSWEISE Abbremsen nach einer Lenkbewegung unterbinden - wäre das euch lieber, bzw. würdet ihr einen zusätzlichen Trainer bevorzugen???
Auf jeden Fall.
Das ist auch nicht der einzige Rückschritt, der mir aufgefallen ist.
Da wären die Bergwände, die nur eine senkrechte Kante sind. Das sah bei Test Drive 1 besser aus.
Und der Radaralarm klingt auch viel besser in Test Drive 1.
Aber ich schätze, daß diese Einschränkungen aus Speicherplatzgründen zustande gekommen sind.
Und dann ist da dieser schwarze Balken über der Armatur. Test Drive 1 hatte da einen grauen Balken, womit er immerhin zur Straße passte.
Video #1 (TD I)
Nicht wirklich. Prüf doch nochmal den Link.
Viel Spaß dabei!
Vielen Dank - den hatten wir! Wir sind beide wirklich sehr glücklich darüber, dass es deinen Patch gibt! Und egal ob du noch Änderungen/Verbesserungen machst - die Schäfchen sind ja schon mal im Trockenen. 
Prüf doch nochmal den Link.
Ach, da ist mir ein kleines Malheur passiert. Wusste zwar, dass ich diesen Link im Forum verwendet hatte, gehörte aber zu diesem Thread:
Eine Pistole für Ringo
Wie gesagt (Post #106) einfach mal miteindander vergleichen. Ich schätze mal ganz grob TD II hat hier gegenüber dem 1 MHz Modus einen Beschleunigunsgfaktor von ca. 3 oder 4. TD I evtl. Faktor 6, aber mind. 30...40 % schneller als der 2. Teil.
Test Drive I:
https://drive.google.com/file/…lpOX0U/view?usp=drive_web
Test Drive II:
https://drive.google.com/file/…mRqREE/view?usp=drive_web
Auf jeden Fall.
Das ist auch nicht der einzige Rückschritt, der mir aufgefallen ist.
Ja, Einiges war im 1. Teil besser. Man kann es sich wie eine Probefahrt zu einem echten Autokauf vorstellen: TD I bietet vom Fahrgefühl das Auto, dass man sich dann später kauft, TD II bietet die schönere und abwechslungreichere Welt, in der man mit dem Auto fahren möchte. So gesehen haben beide Teile ihren Reiz und machen im Turbomodus auch sehr viel Spaß. Mit 1 MHz wäre ich wohl nicht motiviert einen Teil in nächster Zeit nochmal zu spielen.
Und der Radaralarm klingt auch viel besser in Test Drive 1.
Stimmt, vom Radaralarm im 1. Teil kriegt man ja Zahnschmerzen!
- Kann man vom optischen Eindruck sagen, dass M.J.s Patch bei der Fahrgeschwindigkeit in etwa gleich schnell ist - egal ob SuperCPU oder TC 64 verwendet wird?
Auch ist dann der Bildaufbau natürlich sehr flüssig.
Nur zur allgemeinen Erläuterung: Die Simulation der Welt ist (logischerweise) gequantelt. Ein Zeitquantum beträgt stets 6 Bildschirme. Die Graphik ist davon völlig unabhängig. Die Bilder werden einfach in einem zweiten Prozess nacheinander gemalt so schnell wie mögich, aber mit den Daten, die gerade anliegen. Da sich die Daten aber erst nach 6 Bildschirmen komplett ändern, wird die effektive Bildschirmrate auch nie schneller sein. Geschieht das Malen schneller als die Fahrberechnung dauert, wird einfach das gleiche Bild noch einmal gezeichnet. Hätte man also einen 6502 mit 1000Mhz, würde der eine ganze Weile immer das gleiche Bild malen, bis die Routine im Interrupt endlich neue Daten liefert. Das Torkeln bei 1Mhz liegt daran, daß das zur Aktion gehörige Bild erst mit einiger Verspätung angezeigt wird, halt so viel später, wie es eben dauert, die Graphik zu zeichnen, und das ist sehr lange. Wie man aber an dem blauen Kreis auf dem Lenkrad sehen kann, registriert das Programm durchaus die Lenkbewegungen, jedoch fährt man bei 1Mhz immer ein kleines Stückchen blind durch die Gegend und zudem mit einer Zeitversetzung in der Anzeige. So kann sich das Auto real schon kurz vor der Felswand befinden, da aber die Graphik hinterherhinkt, sieht es so aus, als wäre da noch etwas Platz. Eine Beschleunigung des Programms bedeutet also auch eine Reduzierung der Latenz und damit ein genaueres Fahren.
Mit der optimierten Multiplikation sind es aber nicht nur die paar Pixel, die in der Startposition fehlen. Während der gesamten Fahrt treten da am rechten Rand Verzerrungen auf.
Diese Verzerrungen existieren auch in der Originalversion. Wenn man sich z. B. DATA-LANDs Video ansieht (Im Video wird noch eine alte Version gebraucht ohne Änderung der Multiplikation.), kann man sehen, daß der rechte Rand mehrmals nach links abknickt, obwohl er weiter nach rechts verlaufen sollte. Es könnte sein, daß diese Rechenungenauigkeit mit einer präziseren Multiplikation an einigen Stellen deutlicher wird, vorhanden ist sie aber bereits im Original. Um das zu beheben, müßte man die ganze Berechnung überarbeiten. Meine Vermutung zur Zeit geht dahin, daß die Werteskalierung für die perspektivische Darstellung (Straße wird nach hinten schmaler) mittels einer Multiplikation mit einem reziproken Wert für Z realisiert wird (also x' := x * (1/z) anstelle von x' := x / z). Dieser Wert besteht jedoch nur aus 8 Bit, was sehr ungenau ist.
Da wären die Bergwände, die nur eine senkrechte Kante sind. Das sah bei Test Drive 1 besser aus.
Das Spiel ist in eine große Menge von Modulen unterteilt. So existieren für jeden Fahrabschnitt einzelne Module, die zu Beginn der Fahrt geladen werden. Davon gibt es 19 verschiedene. Der Code für die Berechnung der Bergwand befindet sich in solch einem Modul bzw. in allen Modulen der Fahrabschnitte, in denen halt eine Bergwand angezeigt werden soll. Die müßte man alle umprogrammieren. Das sind reichlich viele.
Und dann ist da dieser schwarze Balken über der Armatur. Test Drive 1 hatte da einen grauen Balken, womit er immerhin zur Straße passte.
Die Straßenfarbe in TD II ändert sich allerdings von Fahrabschnitt zu Fahrabschnitt, bei Tunneln sogar während der Fahrt. So oder so müßte zumindest vor jeder Fahrt erneut die Graphik angepaßt werden, und der Code dafür wäre dann wohl in diesen 19 Modulen... ("TD II" ist auch bekannt unter dem Namen "TT II". )
Was meint ihr - angenommen M.J. könnte dieses ZWANGSWEISE Abbremsen nach einer Lenkbewegung unterbinden - wäre das euch lieber, bzw. würdet ihr einen zusätzlichen Trainer bevorzugen???
Was bewegt zur Annahme, ich wäre auch nur ansatzweise in der Lage, solch eine Programmänderung durchzuführen? 
Wie gesagt: Das Spiel besteht aus einer Riesenmenge von verschiedenen Modulen, schätzungsweise über 100.000 Zeilen Programmcode, von denen ich gerade mal ca. 7000 disassembliert habe, und der Code sieht dann auch nur so aus:
Um tiefgreifende Veränderungen vorzunehmen, müßte man erst einmal den ganzen Code disassemblieren und dann auch bis in alle Einzelheiten verstehen. Wie ich schon schrieb, ist der Code bislang nicht relokatibel, weil die Einsprungspunkte der Unterroutinen nicht verschoben werden dürfen. Bei Änderungen muß man also stets darauf achten, daß man nicht mehr Bytes verbraucht als im Original, da sonst die Einsprünge nicht mehr funktionieren. 
Daß der Turbopatch überhaupt möglich war, liegt nur daran, daß das Programm einfach fürchterlich schlecht programmiert ist, so daß durch Ersetzung einiger Graphikroutinen genau die Menge an Bytes frei wurde, die für den Patch benötigt wird. Tut mir leid, Euch daher enttäuschen zu müssen, aber für weitergehende Programmänderungen sehe ich zur Zeit keine Möglichkeit. Sollte TRW im nächsten Jahr eine Compo ausrufen zum Thema "Sportspiele", könnte man allerdings mal daran denken, ein neues Rennspiel im Stil von Test Drive von grund auf neu zu programmieren.
Was mich noch interessieren würde, wäre, ob man auch auf einem normalen C64 eine Steigerung der Bildschirmrate erkennen kann. Hat da jemand mal einen Vergleich vorgenommen?
Das mit dem automatischen Bremsen beim Lenken scheint mir auch nicht so gewollt zu sein. Bei der Amiga-Version tritt dieser Effekt nur ganz minimal auf. Das ist durchaus plausibel, da die Zentipetalkräfte auf die Räder wirken. Aber im Ausmaß einer Vollbremsung ist das natürlich völlig unrealistisch. Dafür reicht die Haftreibung nicht. Der Wagen würde vorher ausbrechen.
Die Simulation der Welt ist (logischerweise) gequantelt.
Ich erinnere mich noch vage an einen frühen Beitrag, in dem ein Leser schrieb, dass mit seinem TC64 das Spiel nicht schneller, aber flüssiger läuft. Zumindest profitiert die Lenkung ja schon mal gut davon. Wenn ich an der SCPU allerdings den Schalter von 1 auf 20 MHz und wieder zurückbewege, sehe ich sehr wohl auch eine Geschwindigkeitsveränderung. Daher die Frage ob das Spiel mit dem TC64 evtl. schneller oder langsamer abläuft als mit der SCPU.
Im Video wird noch eine alte Version gebraucht ohne Änderung der Multiplikation.
Ich chabe für die Videos zu spät von der neuen Version erfahren. Habe sie aber inzwischen runtergeladen und werde sie morgen testen...
Was bewegt zur Annahme, ich wäre auch nur ansatzweise in der Lage, solch eine Programmänderung durchzuführen?
Dein Tatendrang, dein Forscherdrang, dein Interesse am Knobeln???
Nun - es ging zuerst mal darum abzuklopfen, wie die Fahrer darüber denken. Vielleicht ist ja eine diesbezügliche Änderung gar nicht erwünscht.
Im anderen Fall könnte man den Kode auf die Portabfragen ($DC00) "durchschnüffeln", da die Geschwindigkeitsabsenkung im Idealfall als Subroutine ab einer bestimmten Lenkradbewegung (L/R) aufgerufen wird. Ich müsste nochmal das Bremsverhalten beim starken Lenken und beim gewollten Bremsen (JOY UNTEN) betrachten. Wenn der Effekt gleich ist, wird u.U. die gleiche Subroutine für beide Fälle verwendet. Die Portabfrage müsste sie dann also auch 2, bzw. 3 x aufrufen (JOY UNTEN oder JOY LINKS/RECHTS).
Wie ich aber auch schon sagte, ist das Ziel ja eh schon erreicht.
Ich hab gerade auch mal die DOS-Version in DOSBox ausprobiert. Die bremst auch beim Lenken sehr stark ab. Was mir außerdem auffiel, daß beim erneuten Fahren exakt die gleichen Fahrzeuge an den gleichen Stellen unterwegs sind. Auf anderen Systemen ist das sonst Zufallsgesteuert.
Und obwohl es Tandy in 16 Farben kann, habe ich keinen Tandy-Sound. Ich weiß aber nicht, ob das am Spiel oder an DOSBox liegt.
Die Bildrate scheint auch auf allen Systemen mit ausreichend CPU-Power die gleiche zu sein, und Test Drive 1 scheint mir auch jeweils leicht flüssiger zu sein. Das deutet sehr darauf hin, daß die Berechnungen auf verschiedenen Systemen sehr ähnlich sind.
Auf anderen Systemen ist das sonst Zufallsgesteuert.
Beim CeVi doch auch, oder?
Und was würdest du beim Geschwindigkeitsvergleich SCPU und TC64 sagen? Kein Unterschied sichtbar, oder?
Habe mal etwas im Kode gestöbert:
- Main IRQ ($FFFE) -> $7FAD
- VIC Bank 3 aktiv, Zeiger der Armaturen Sprite-Datenblöcke #002 + #003 bei $C080 und $C0C0
- Keine Kopien aus einer Zeigersammlung, bzw. Umschalten div. Datenblöcke, sondern jewiliges Hineinpixeln.
- Register $0CA0 = $00/$FF -> Spiel/Demomodus
- Register $0CA1 = $00/$FF -> Man./Automatikgetriebe
- Joystickabfrage $6DF9...$70BB, Aufruf von $8386
- Low-Nybble von $DC00 mit Vergleich von Tabelle ab $5441 entspricht bspw. JOY UNTEN, also %00001101 = $05. Wird testweise $05 durch bpsw. $01 ersetzt, gibt es statt dem Bremsmanöver nun Vollgas.
- Wird bei $6ED8 und $6F25 je eine Brücke mit JMP $6F75 gemacht, wird beim Lenken das Abbremsen unterbunden. Allerdings mit furchtbaren Nebenwirkungen: Das Lenkrad bewegt sich nicht mehr und die Lenkwirkung ist schwach.
Mit den 2 genannten JMP Befehlen wird natürlich äußerst rüpelhaft die lästige Bremsfunktion übersprungen, aber wie auch schon der o.g. Test mit dem Tabellenwert $01 statt $05 gezeigt hat, muss in dieser Routine der Grundstein für die Steuerung und dem ungewollten Abbremsen liegen. Ich bräuchte auf jeden Fall mehr Zeit um mir das alles mal in Ruhe anzuschauen und div. Tests zu machen.
Vielleicht möchtet ihr ja auch mal selber einschauen? Wie gesagt $6DF9...$70BB. Die dazugehörigen Subroutinen für Lenken, Gasgeben und Bremsen habe ich noch nicht gefunden. Sie müssten aber zwangsläufig auch die 2 erwähnten Spritezeiger bei $C080 und $C0C0 aktualisieren.
Den Test mit der neuen Betaversion werde ich dann morgen Abend nachholen!
