www.vierpfeile.de

Scorpion hat geschrieben:Er sendet sie sogar so früh, dass die Signale mit dem Lag des Adapters noch zu früh ankommen! Wer das Teil programmiert hat ...

Handelt es sich bei der DLL um die selbe, die in RC2 bereits integriert sein soll? Vielleicht funktioniert es ja mit der nativen Unterstützung des RC2 besser?

Scorpion hat geschrieben:Zurück zum Vergleich Xbox Controlbox - Adapter:

Verwendest Du den EMS2 Adapter?

Scorpion hat geschrieben:Ich hab mich einfach doch mal am Autoadjust versucht und es kamen unbrauchbare Werte heraus(hochschaukeln ).

Also wer auch immer die gemoddete SM-Version gemacht hat, kann sich doch nicht soo anstellen. Was ist denn daran, das er sie nicht veröffentlichen will? Egoismus? Egal...

Scorpion hat geschrieben:Vielleicht kann man diese aber irgendwie auswerten, wenn man weiss, wie Auto Adjust genau funktioniert, [...]

Da nach diesem zweiten Test es erneut den Anschein hat, das SM immer gegen die zu früh sendende Lights-DLL gegensteuert, würde ich sagen, das wir den Auto-Adjust abschreiben können. Es sei denn wir führen einen Ein-Pfeil-Test mehrfach durch...

Scorpion hat geschrieben:oder man kann diese Werte bei 2 verschiedenen Liedern in irgendeine Verbindung bringen.

Wobei...da fällt mir auf: Die Lights-DLL sendet doch immer eine BESTIMMTE Zeit (+/- ein paar ms Lights-DLL-Ungenauigkeit(?) und LPT-Lag) zu früh an SM. Und SM steuert doch immer EXAKT gegen diese Verzögerung. Also müsste doch die gesamte Verschiebungszeit (Hochschaukeln) von SM am Ende eines Liedes durch die Gesamtzahl aller Pfeile des selben Liedes die ms-Verschiebung EINES Pfeiles ergeben, oder? Und wenn man dasselbe Lied mehrfach durchlaufen lässt, sollte auch die Oben erwähnte Unschärfe sich statistisch wegrechnen lassen (z.B. Durchschnitt von 100 Durchläufen ). Insofern hast Du intuitiv richtig gelegen: Man kann dieses Prinzip des Teilens auf jedes Lied übertragen und so meinetwegen die Lieder in einen Bezug zueinander stellen, um so auf die ms-Verschiebung pro Pfeil zukommen. Der Wert der am Ende rauskommt hat jedoch noch keine Aussage: er enthält sowohl das Zufrühsenden der Lights-DLL als auch das Zuspätsenden des jeweiligen Adapters. Interessant wird es allerdings, wenn Du die Adapterwerte in Relation stellst. Die Differenz der Millisekunden-Verschiebeungen der beiden Adapter pro Pfeil, stellt gerade die wahre ms-Differenz zwischen den Adaptern dar. Somit könnten wir zwar nicht sagen um wieviel die beiden Adpater langsamer sind, aber immerhin um wieviel ms sie sich wirklich voneinander unterscheiden!!

Scorpion hat geschrieben:Ich hab mit den Timewindows so lange rumgespielt, bis ich Grenzwerte getroffen hab, wo aus dem Perfect plötzlich nur noch ein Great wird.

Korregiere mich wenn ich was falsches sage, aber meine Konzentration lässt allmählich nach: Wäre es nicht besser zunächst per Hand den Offset in der StepMania.INI solange zu verschieben, bis die zu frühgesendeten Lights-DLL Signale ALLE Marvellous sind und dann das Timewindow von Marvellous solange zu verkleinern bis Perfects auftreten, um die ms-Schwankung herauszufinden? Und auch wenn das annähern in 5ms-Schritten zunächst ausreicht, sollte man in 1ms-Schritten weiter machen, da wir ja eine Reihe von Schwankungen haben und nicht auch noch mit ungenauen Nährungswerten das Ergebnis verfälschen wollen.

Scorpion hat geschrieben:Xbox Controlbox:
JudgeWindowSecondsMarvelous=0.045000
JudgeWindowSecondsPerfect=0.050000
Adapter:
JudgeWindowSecondsMarvelous=0.005000
JudgeWindowSecondsPerfect=0.020000

Wenn Du die ms herausbekommen willst nach Deiner Methode: Marvelous stellt ja so ziemlich die Mitte von der Zeitleiste dar (+/-5ms) und die Scores liegen ja zwischen Perfect(+20ms) und Great (+35ms). Also von 0ms ausgehend: +Marvelous-Timing +Perfect-Timing um genau zwischen Perfect und Great Millisekunden-technisch anzukommen. Macht also 25ms für den Adapter und 95ms für die Xbox-Controlbox. Wie Du sicherlich bemerkt hast kann der Wert für letztere ja nicht hinhauen. Irgendeinen Fehler beim Copy&Paste gemacht?!

Hier noch ein 'Schaubild' für das Adapter-Rechenbeispiel:
Good(-45ms) Great(-35ms) Perfect(-20ms) Marvelous(-5ms) 0ms Marvelous(+5ms) Perfect(+20ms) Great(+35ms) Good(+45ms)

Scorpion hat geschrieben:Das ergibt einen Lag von 7,5 ms, schwankend, was wiederum bedeutet, dass der Offset 3,75ms sein muss, damit man im Durchschnitt bessere Werte erzielt. Dies bezieht sich natürlich nicht auf den statischen Lag der Xbox (wenn es einen nennenswerten gibt), den ich mit diesen Mitteln nicht herausfinden kann. Weiterhin kann man diesen schwankenden Lag wohl zu mind. 90 % dem Druckerport zuschreiben, da er ohne irgendwelche Tweaks bestimmt nicht auf geeigneten Takraten läuft.

Du kannst den Großteil des Lags nicht dem LPT zu schreiben, da ja eine Reihe von Leuten hier im Forum sich positiv über den LPT-Mattenadapter geäußert haben. Und wenn der 'spürbar' besser ist als der +/-8ms-USB-Port, dann muss die Controllbox einen beachtlichen Anteil am Lag haben.

Scorpion hat geschrieben:So, jetzt habt ihr euren Beweis zum Thema Adapter und DDR-tauglichkeit

Noch nicht Und sei beim nächsten Test ein wenig unvoreingenommener. Das der Adapter nicht des Weisheits letzter Schluß ist, ist auch so schon klar

Scorpion hat geschrieben:Behaltet die Denkfehler doch nicht, helft mir

Gern geschehen. Ich hoffe ich konnte ein wenig Licht ins Dunkel bringen und Dich nicht nochmehr verwirren...

Ich hatte noch gerade ein paar weitere Geistesblitze, nachdem ich mal schematisch den Kreislauf unseres Testaufbaus aufgezeichnet hatte:

-Wir können nicht den korrekten Wert direkt messen, da allein durch USB (+/-1ms), LPT (+/-?ms) und LPT-zu-Joypad Elektronik (-/+?ns) eine Unschärfe entsteht.

- Deswegen kam mir die Idee, ob es nicht möglich ist, den LPT-Port direkt an die Xbox Controlbox anzuschließen, um rauszufinden, wieviel ms-Verschiebung wir durch LPT, Elektronik und USB zu erwarten haben. Da der USB-Wert bereits bekannt ist, würde die Differenz für LPT und Selbstgebastelte Elektronik stehen. Diesen Wert könnten wir von unseren Auto-Adjust-Werten abziehen, da sowohl LPT wie auch Elektronik im realen Betrieb mit Matte gar nicht vorkommen.

-Im jedenfall werden wir nur auf den präzisen Wert kommen, wenn wir mehrere Testdurchläufe durchführen und statistisch die Unschärfe ausradieren. Die Masse machts...

-Der Ein-Pfeil-Test erscheint insofern gar nicht mal so abwägig, da er schnell durchzuführen ist, und das Obige Divisions-Gerechne nicht mehr notwendig ist, weil wir gleich die ms-Verschiebung von einem Pfeil im Auto-Adjust-Mode mitgeteilt bekommen. Auf der anderen Seite enthält ein Standard-Lied viele Pfeile. Eine Divisionsrechnung würde also gleichzeitig zu einem bereinigten Wert führen, weil im Verlauf des Liedes ja eine Menge +/-Verschiebungen stattgefunden hätten, oder wie jetzt? Hä? Ich brauch eine Pause...

PS: MEIN HUNDERTSTER POST! Cool... Ich glaub' den rahm' ich mir ein...

Sooo, bin fertig mit dem Lightsdrivertest.

Um das ganze übersichtlich zu gestalten, beantworte ich erstmal deine Fragen:

1.
Ja, es ist RC2

2.
Nein, es ist der S-Joy Titanium, anscheinend baugleich zum Superjoy Box3. Ist bei den Playasia Pads dabei. Ich würd mir aber nicht zu viele Hoffnungen darüber machen, das andere Adapter weniger Lag verursachen. Wenn ich welche in die Finger bekomme, werde ich diese aber mal genauer testen.

3.
Ja das ist ja das Problem, wir wissen nicht genau, wie AutoAdjust die Pfeile anpasst. Das mit dem durch die Pfeile teilen hab ich mir auch schon überlegt, aber dazu später.

4.
Die Lightsdriver sind auch vom Offset abhängig, also bringt das verschieben des Offsets nix. Weiterhin sind die 5 ms Schritte eigentlich 2,5 ms Schritte (schon ziemlich präzise), weil die Timewindows ja zur hälfte in beide Richtungen vom Punkt 0 ausgehen.

5.
Sry, Perfect und Great war nur ein Beispiel, der Lag liegt zwischen Marvelous und Good. Ich versteh aber trotzdem nicht, wie du auf die Zahlen kommst. Die Differenz zwischen Perfect und Great beträgt 5ms bei der Xbox CB und 15ms bei dem Adapter. Die Werte müssen dann wieder durch 2 geteilt werden, da die Timewindows ja in beide Richtungen gehen und bei uns nur die eine Richtung in Frage geht.

6.
Es müsste eher so aussehen:

Good(-22.5ms) Great(-17.5ms) Perfect(-10ms) Marvelous(-2.5ms) 0ms Marvelous(+2.5ms) Perfect(+10ms) Great(+17.5ms) Good(+22.5ms)

7.
Diese Leute kennen den LPT Adapter im Vergleich zu USB Adaptern, da sind die 8ms Standardwert von USB erstmal unrelevant. Wie du schon an dem Lagexperiment sehen kannst, erzeugt der USB Adapter von sich aus schon einen größeren schwankenden Lag als die 8ms. Ich würde den LPT Adapter auch gerne ausprobieren, hab aber leider keine 2 Ports. Ausleihen würde ich mir einen, aber kaufen ..

8.
Der 2. Test bestätigt den ersten noch einmal, damit ist der Nachteil von USB Adaptern eindeutig. Problem ist demnach gar nicht der Offset, der schon nicht ohne ist, sondern viel mehr der schwankende Lag, den man nur durch einen Ersatz des Adapters weg bekommt.

9.

LPT Zu Joypad Elektronik fällt weg, da diese Elektronik nur ein einziges Bauteil ist. Ich bin zwar nicht sicher, wie viel Delay das momentane hat, ich vermute aber mal, das der unrelevant ist. Ich kann das Bauteil aber noch durch ein anderes austauschen, dann liegt der Delay bei einem Bruchteil einer ms.
Solange der Lightsdriver nicht im Moment 0 sendet, seh ich keine Möglichkeit, da was mit SM zu machen.
Bei deinen Überlegungen finde ich den Lag vom Computer außerdem nicht wieder. Der wird mit Sicherheit auch noch seinen Teil dazu beitragen.

Dieser Ein-Pfeil-Test dauert zu lange und ich weiss auch nicht, ob SM überhaupt einen Wert anzeigen wird. Ich hab mal auto adjust angemacht und nach einem Pfeil abgebrochen, es kam einfach kein Wert. Weiterhin ist dieses Offsetgerechne doch sehr präzise, sodass man den Offset daraus zuverlässig berechnen kann.
Ich glaub am zuverlässigsten wär es in einem Realtime Betriebssystem den LPT Port mit Realtime anzusteuern und ein Signal an das Eingabegerät zu schicken. Dieser Delay wird gemessen und man hat mit ziemlicher Sicherheit den Lag des Eingabegerätes. Aber lohnt sich der ganze Aufwand wirklich?
Und wie gesagt, das größte Problem ist der schwankende Lag bei den Adaptern.

So werd mich nun dran machen, die Ergebnisse vom 2. Test zusammenzufassen. Mal sehen wie lang es dauern wird ^^


EDIT:
Argh, grr mist! Kleiner Fehler unterlaufen, werd die Messungen nochmal machen müssen

EDIT2:
Hab nochmal geguckt wegen den Druckerport Adaptern. Hab folgende Treiber gefunden:

Directpad Pro
NTPad
PPjoy
PSXpad

Bei NTPad hab ich in der Changelog was zum Thema Zuverlässigkeit gefunden. Die ersten Versionen hatten um die 10 Hz, bei den neuesten steht etwas von "100-500Hz".
Zu DirectPad Pro scheint es in der Windows Registrierung einen Wert über die Scanrate zu geben:

http://www.arcadecontrols.com/Mirrors/w ... xtend.html

Scorpion hat geschrieben:Ja, es ist RC2

Möchtest Du es dann nichtmal mit der DLL die ich verlinkt hatte versuchen, oder ist das dieselbe?

Scorpion hat geschrieben:Das mit dem durch die Pfeile teilen hab ich mir auch schon überlegt, aber dazu später.

Hab ich etwas übersehen, oder hast Du später vergessen zu dieser Rechenmethode was zu sagen?

Scorpion hat geschrieben:Die Lightsdriver sind auch vom Offset abhängig, also bringt das verschieben des Offsets nix.

Ich kann Deiner Logik nicht folgen... Was meinst Du, wie Auto-Adjust denn sonst funktioniert (Thema: Hochschaukeln)? Ist es nicht gerade das Problem, das Auto-Adjust nach jedem Pfeil den Offset entsprechend dem zu früh 'treten' der Lights-DLL nach hinten verschiebt? Dann sollte doch der Offset eine Auswirkung auf das Timing haben?!

Scorpion hat geschrieben:Ich versteh aber trotzdem nicht, wie du auf die Zahlen kommst. [...] Good(-22.5ms) Great(-17.5ms) Perfect(-10ms) Marvelous(-2.5ms) 0ms Marvelous(+2.5ms) Perfect(+10ms) Great(+17.5ms) Good(+22.5ms)

OK, das wird jetzt etwas schwierig:
1. Mein Fehler, ich dachte das z.B. die 5ms von Marvelous in beide Richtungen von 0ms ausgehen (also insgesamt 10ms).
2. Selbst nach Deiner (richtigen) Zeitleiste komme ich auf andere Werte. Du sagst dass das Lag zwischen Marvelous und Good liegt. Da Pfeile ja auch im Marvelous-Bereich liegen, sind (auch wenn die Lights-DLL zu früh sendet) einige Pfeile im Bereich zwischen 0ms und +2,5ms gelandet. Also ist die linke Intervallgrenze 0ms! Das Good-Fenster hört bei +22,5ms auf und stellt somit die rechte Intervalgrenze dar. Jetzt könntest Du natürlich sagen dass das Intervall 22,5ms insgesamt umfasst und da ja die meisten Pfeile bei Perfect und Great liegen das die Hälfte dieses Wertes (11,25ms) das Lag darstellt. Das ist aber nicht so einfach. Dazu müssten ja Marvelous-, Perfect-, Great- und Good-Fenster exakt gleich groß sein. Das sind sie aber nicht: Allein das Marvelous-Fenster ist nur +2,5ms nach rechts groß. Da Du willkürliche Perfect- und Great-Timewindows angegeben hast, kann ich nicht sagen, wie es sich bei denen verhält. Mein Rechenansatz war folgender: Ausgehend von der linken Intervallgrenze 0ms kommen x ms für die rechte Hälfte des Perfect-Windows (das auch die rechte Hälfte des Marvelous-Fenster beinhaltet) dazu und erst dann sind wir rechnerisch zwischen Perfect und Great gelandet. Aber aus Mangel an korrekten Timewindow-Werten kann ich Dir keine konkreten ms-Werte für die Adapter nennen. Da das Lag (beim Superjoy übrigens) zwischen 0ms und 22,5ms liegt würde ich Dir für einen Test vorschlagen die vier Zeitfenster zu vier gleichen Teilen einzustellen. Die Formel dazu lautet 22,5(Lag insgesamt)/4(Anzahl der Fenster)*2(beide Richtungen)*1(erstes Fenster). Also:
(22,5/4)*2*1 macht 11,25ms für Marvelous.
(22,5/4)*2*2 macht 22,5ms für Perfect.
(22,5/4)*2*3 macht 33,75ms für Great.
(22,5/4)*2*4 macht 45ms für Good.
Zeichne Dir am besten nochmal die Zeitleist von -22,5ms über 0ms bis +22,5ms auf, dann ist das ganz einfach nachzuvollziehen.

Scorpion hat geschrieben:Diese Leute kennen den LPT Adapter im Vergleich zu USB Adaptern, da sind die 8ms Standardwert von USB erstmal unrelevant. Wie du schon an dem Lagexperiment sehen kannst, erzeugt der USB Adapter von sich aus schon einen größeren schwankenden Lag als die 8ms.

Jein. Der USB-Port wird NUR alle 8ms ausgelesen. Sollte des Adapter in der zwischen Zeit das Signal versucht haben zusenden, wird es erst nach den nächsten 8ms erkannt. Aber da Du eh auf 1000Hz gegangen bist, ist die USB-Port 'Ignoranz' bei 1ms angekommen und der Adapter am Lag Schuld...

Scorpion hat geschrieben:Der 2. Test bestätigt den ersten noch einmal, damit ist der Nachteil von USB Adaptern eindeutig. Problem ist demnach gar nicht der Offset, der schon nicht ohne ist, sondern viel mehr der schwankende Lag, den man nur durch einen Ersatz des Adapters weg bekommt.

Sprech mir nach: Wir tun uns das alles hier an, um den Millionen von Softmatten-Besitzern da draußen einen pauschalen Offset-Wert für jeden Adapter nennen zu können, damit sie das (mathematisch) bestmögliche Spielerlebnis haben können und SM sich ein wenig neben Arcades behaupten kann. Wir sind uns bewußt das uns nur Undank, Missverständis und ein lausiges VierPfeile-T-Shirt winkt, aber wir sind voll von Überzeugung für unsere ehrenswerten Ziele (das Allgemeinwohl der Welt)...

Scorpion hat geschrieben:Ich bin zwar nicht sicher, wie viel Delay das momentane hat, ich vermute aber mal, das der unrelevant ist. Ich kann das Bauteil aber noch durch ein anderes austauschen, dann liegt der Delay bei einem Bruchteil einer ms.

Kleinvieh macht auch Mist... Und wir versuchen ja gerade einen Wert zwischen 0ms und 20(?)ms zu finden, da kann die eine oder andere ms schon tierisch ins Gewicht fallen. Aber solange Du keine Optokoppler verwendest sag ich nichts...

Scorpion hat geschrieben:Bei deinen Überlegungen finde ich den Lag vom Computer außerdem nicht wieder. Der wird mit Sicherheit auch noch seinen Teil dazu beitragen.

Mein Fehler, oder auch nicht. Ich gehe ja schließlich von einem super-flüssig laufenden System wie bei uns Lag-Freaks aus... Für die anderen Systeme existiert ja mittlerweile der Defragmentierungs-Thread. Vielleicht mache ich auch noch ein paar andere. Die können wir dann sticky machen und nie wieder soll dann einer Fragen "Was muss ich für eine PERFEKTE SM-Maschine machen?" Und ich muss mir nicht mehr all diese elenden Threads über empirische Vermutungen anschauen...

Scorpion hat geschrieben:Dieser Ein-Pfeil-Test dauert zu lange und ich weiss auch nicht, ob SM überhaupt einen Wert anzeigen wird. Ich hab mal auto adjust angemacht und nach einem Pfeil abgebrochen, es kam einfach kein Wert.

Kleines Missverständnis: Ich meinte, wir sollten ein Ein-Pfeil-Lied _selbermachen_. Das Auto-Adjust bei Abbruch nichts rauswirft scheint logisch.

Scorpion hat geschrieben:Hab nochmal geguckt wegen den Druckerport Adaptern. Hab folgende Treiber gefunden: [...] Die ersten Versionen hatten um die 10 Hz, bei den neuesten steht etwas von "100-500Hz".

Merkwürdig, ich dachte das Windows genauso wie den USB-Port den LPT-Port über ein (modifizierbare) DLL steuert. Wenn Du aber von Treibern redest scheint dieser ja von sich aus gar keinen Lag zu besitzen. Der hängt anscheinend vom Treiber ab. Ein solcher müsste dann also auch in der Lights-DLL oder SM eingebaut sein. Orientieren wir uns an den Werten oben, dann sollte der LPT einen Lag von ~8ms bis 2ms aufweisen. Dann rechnen wir Deinen USB-Lag (1ms) dazu und kommen somit auf 3ms bis 9ms Lag. Den können wir dann von den errechneten Offsets abziehen und sollten dann nach mehreren Tests (Schwankungen) den exakten ms-Offset der Adapter herausfinden.

Kleine Bemerkung am Rande: Der Thread mag ja riesig sein, aber ich denke das wir der Lösung sehr nahe sind. Scorpion und ich quatschten ja in der Regel nur über Feinschliff und Missverständnisse.

1. Ist dieselbe DLL

2. Das war eigentlich Bestandteil des 2. Tests, den ich noch neu machen muss

3. Das war auf den GlobalOffset bezogen. Du hast vorgeschlagen den GlobalOffset solange anzupassen, bis der Lightsdriver sync wird.

4. Genau so wars auch im 2. Test geplant, ich bin dir schon zuvor gekommen Allerdings ist mir bezüglich der Zeitfenster am Ende des Tests ein Fehler aufgefallen. Werde demnächst vervollständigen.

6. Offset steht erst an zweiter Stelle nach dem schwankenden Lag. Offset bringt eigentlich nur soweit was, wenn man an der AC spielt und sich nicht an den ungeheueren Unterschied umgewöhnen muss. Du weißt doch selber am besten, wie schnell man sich an den Offset gewöhnt hat
Werde das zwar nicht aus den Augen verlieren, aber das Problem des schwankenden Lags kriegt man eben nicht weg.

7. Kein Optokoppler

8. Für eine perfekte Maschine müsste der Computer alles sofort abarbeiten und es darf vom Computer kein Lag entstehen. Für solche Zwecke gibt es extra Echtzeit Betriebssysteme, bzw Echtzeitkernel für vorhandene. Dann muss SM aber darauf ausgelegt sein, ich hab kP wie das funktionieren soll. Ohne diese Echtzeitsachen kannst du von vornherein kein perfektes Stepmania machen.

9. Wie gesagt, später mehr

10. Wir können die Infos von dem einen Treiber nicht einfach irgendwie übertragen, da es ganz auf den Treiber ankommt. Der Treiber kann auch gar keinen Lag haben. Und ohne Echtzeit kannst du den Lag vom PC nicht wissen. Das einzige, was wir 100 % berechnen können, ist der Unterschied Xbox CB - Adapter.

11. Ja und leider viel zu oft über Missverständnisse *gg

Wo wir gerade bei missverstehen sind:

Scorpion hat geschrieben:6. Offset steht erst an zweiter Stelle nach dem schwankenden Lag. [...] Werde das zwar nicht aus den Augen verlieren, aber das Problem des schwankenden Lags kriegt man eben nicht weg.

Wenn Du ein und denselben Test 1.000.000 Mal durchführst, dann kannst Du Dir sicher sein, dass das Schwanken stochastisch wegfällt und nur der bereinigte Adapter-/Xbox CB-Offset übrig bleibt! Wenn wir diesen Offset dann in die INI eintragen, dann sind die Schwankungen um den optimalen Wert herum und vermasseln die Highscore 'gleichmäßig'. Ansonsten ist das z.B. so, das der Adapter zu spät ist und das Schwanken das Ganze noch später macht und insgesamt Alles viel zu spät ist. Wenn aber das Einzige, was Dich von 0ms wegbringt das Schwanken ist, dann wäre das besser für die Highscore.

Scorpion hat geschrieben:8. [...] Für solche Zwecke gibt es extra Echtzeit Betriebssysteme, bzw Echtzeitkernel für vorhandene.

Also das Einzige was mir dazu einfällt ist der Windows Task-Manager, in dem man irgendeinem Prozess (unter "Prozesse" Rechtsklick auf den Prozess und dann "Priorität festlegen") die Einstellung "Echtzeit" zuweisen kann. Dann kannst Du aber _NICHTS_ anderes mehr machen. Probier das mal aus und schau, ob die Festplatte und der LPT-Port dadurch nicht zu sehr laggen.

Ansonsten bin ich seeeeehhhhrrr gespannt auf die zweite Testrunde.

Ich nehme an, er redet nicht von Windows...

Ja, vielen Dank LostTemplar für deinen sarkastischen Kommentar. Der hat uns jetzt unglaublich weitergebracht. Vielleicht möchtest du die fett gedruckte Passage weiter oben zum Thema Grober Undank lesen...

Egal. Ich hab gerade die Sache mit "Echtzeit" zweimal getestet und musste festellen, das SM so was von flüssig dabei läuft. Die Auslastung des restlichen Systems war aber nicht so hoch wie erwartet (wie bei anderen Programmen das sonst passiert): Man kann locker per Alt-Tab wechseln und mit dem etwas langsamer reagierendem Windows XP weiter arbeiten (hatte Auto-Play aktiviert und nur mal so die Startmenüordner aufklappen lassen). Allerdings habe ich gerade festgestellt, das wenn man doch noch andere Programme offen hat, das die Pfeile ein bischen 'unruhiger' werden.

Führe mal wie gesagt ein Test mit "Echtzeit"-Prozess aus. Würde mich mal interessieren in weit die beobachteten absolut flüssig scrollenden Pfeile ein Aussage für die Messungen haben.

Ja genau, für ein "perfektes" SM wäre Linux bestimmt sowieso die bessere Wahl. Ich kann es aber nicht ausprobieren, da meine Grafikkarte unter Linux aus irgendeinem Grund nicht mit Vsync funktioniert. Dazu kommt noch, dass ich mich nicht mit Linux auskenne

Die Priorität Echtzeit von Windows istn Witz, das hat rein gar nichts mit Echtzeit zu tun. Ich hab im 2. Test das auch schon getestet, aber es gab keine Veränderungen. Naja, bei diesem 2. Test hatte ich die Timewindows falsch gesetzt, sodass das letzte Fenster von der Größe anders war als die restlichen, deswegen muss ich es eben nochmal machen :-/
Aber da sah man schon, dass sich die Werte nicht verändert haben.
Die Priorität hoch zu setzen hilft bestimmt nur dann, wenn du viele anderen Sachen offen hast. Ich hab bei meinem BS für SM aber nur SM installiert und auch fast alle Dienste von Windows deaktiviert, die normalerweise noch im Hintergrund laufen (Systemsteuerung/Verwaltung/Dienste)



Offset:
Der Adapter hat im Durchschnitt 15 ms Lag. Wenn du nun von AC Timing ausgehst, hast du um die 15 ms für ein Marvelous. Das heisst, dass es durch den Adapter unmöglich ist, ein Marvelous zu 100% zu bekommen, da sich das Timewindow bei jedem Step so stark verschiebt.

Scorpion hat geschrieben:Der Adapter hat im Durchschnitt 15 ms Lag. Wenn du nun von AC Timing ausgehst, hast du um die 15 ms für ein Marvelous. Das heisst, dass es durch den Adapter unmöglich ist, ein Marvelous zu 100% zu bekommen, da sich das Timewindow bei jedem Step so stark verschiebt.

Ich glaub' Du verwechselst da etwas: 15ms-Adapter-Lag bedeutet, dass das Signal 15ms später bei SM eintrifft und nicht das 15ms lang funkstille herrscht. Das einzige in dieser Richtung wäre der USB-Port, der standardmäßig nur alle 8ms auf Signale prüft. Aber das Problem wird ja durch den USB-Patch auf bis zu 1ms reduziert.

Nochmal: Wenn wir GlobalOffsetSeconds=0.015000 eintragen, dann wäre die optische Pfeilverzögerung verkraftbar und wir würden immer exakt treten. Das einzige was uns vom 0ms-Step abhält wäre dann der USB-Port, der das Ergebnis um +/-1ms verfälscht, was jedoch immernoch _locker_ im Marvelous-Timewindow wäre. Jedoch brauchen wir dazu ein präzisest mögichen Adapter-Lag-Wert in Millisekunden... Alles unklar?!

Und das Windows alles andere als ein "Echtzeit"-Betriebssystem ist, ist wohl jedem klar. Die Frage ist nur, ob man es in diese Richtung boxen könnte. Was mit Windows XP (aus Mangel an DOS-Unterbau) nicht mehr geht, ist der 'Trick', statt dem Explorer den Kommandozeilen-Interpreter als Benutzeroberfläche zu starten. Da waren alle Unnützen Multitasks raus aus dem Speicher und der Rechner gleich ein ganzes Stück schneller (hatte damals eine lahme Krücke). Die Systemdienste in Windows XP auszuschalten ist sicherlich ein Zugewinn, jedoch nicht vergleichbar. Es müsste echt mal 'ne Möglichkeit geben, etwas anderes als den Explorer zu starten. Was meintest Du übrigens mit Echtzeit-Kernel für Nicht-Echtzeit-Betriebssysteme. Gibt es zufälliger Weise auch einen für XP? Wohl eher nicht, oder?

Ich mein es wirklich so, wie ich es geschrieben hab:

Das, was USB auf Standardeinstellung mit diesen 8 ms macht, das macht der Adapter von sich aus schon mit 15 ms(mindestens!). D.h. der Lag liegt zufällig im Bereich zwischen 0 und 15 ms (abgesehen von dem statischen Lag, den es auch noch gibt). Ich werd versuchen den 2. Test heute noch zu machen, dann siehst du es auch an den Ergebnissen.

Wegen Echtzeit-Kernel:
http://www.nematron.com/HyperKernel/index.shtml

Da steht was von NT/2000, aber XP könnte auch gehen.

http://www.sybera.de/

Ob das wirklich Kernel sind oder was auch immer, kA, aber es wird bestimmt nicht reichen diese Dinger einfach zu installieren.

Von dem Nematron Teil gibts ne Demo Version. Könnte höchstens ausprobieren das Teil zu nehmen und damit die Priorität ganz hoch zu setzen.

Aha, dann nenn's doch bitte in Zukunft Adapter-Schwankung und nicht -Lag, da ich unter Letzteren eine Konstante verstehe. Und was die Höhe der Adapter-Schwankung angeht: Glaubst Du wirklich das die soo hoch ist? Wenn der Adapter mehr Verzögerung verursachen kann als die USB-Pollrate, dann dürften die Leute doch hier im Forum nicht posten, dass das Spielgefühl mit 1000Hz nun weniger 'schwammig' sei. Was nützt's wenn der USB-Port superschnell ausliest und der Adapter nur alle 15ms sendet?!

Außerdem musst Du mir mal erklären, wie Du darauf kommst, das der Adaper zwischen 0ms und 15ms schwankt? Elektronisch gesehen macht das doch gar keinen Sinn: Bisher sind wir doch davon ausgegangen, das die Adapterelektronik an sich der Grund für einen (konstanten, weil immer dieselbe Elektronik) Lag verantwortlich ist. Unter 'Schwankung' verstehe ich, das zwei oder mehrere Interfaces nur in begrenzten, unterschiedlich großen Zeitfenstern arbeiten können, die alle zueinander zeitlich variabel veschoben sind: Je nach Überlappung der Zeitfenster der Geräte kommen Signale (teilweise) durch die gesamte Verbindungsstrecke oder - wenn sie nebeneinander liegen - kommt es zu einer Unterbrechung. Die Fenster-Varianzen führen zu den 'Schwankungen': Zum Beispiel sind Fenster 1 und 2 überlappt, 3 jedoch nicht. Das Signal kommt bis 2 und kann erst weiter, wenn es zu einer Überlappung von 2 mit 3 kommt. Wenn alle drei Fenster zufälligerweise überlappen, kommt das Signal sozusagen mit 0ms durch. Wenn alle drei Fenster nebeneinander landen kommt es zur vollständigen Signalunterbrechung (15ms). Die Varianz wiederum ensteht durch die unterschiedlich (konstante) Größe der Zeitfenster: LPT (3ms), USB (8ms). Das Signal kommt nur bei jedem Vielfachen des kleinsten gemeinsamen Vielfachen (KGV) glatt durch. Also bei 0ms, 24ms, 48ms, usw... Je weniger Fenster (Deine Xbox-CB Argumentation) und je kleiner (USB-Patch, Realtime), desto weniger Schwankungen sind zu erwarten.

Hier die Ergebnisse vom 2. Test:

Es hat sich im Grunde nicht viel geändert, ich hab nur die Timewindows etwas angepasst.

Die Timewindows sind nun so genau wie nur möglich angepasst:


xbox:
JudgeWindowSecondsBoo=0.057500
JudgeWindowSecondsGood=0.053500
JudgeWindowSecondsGreat=0.049500
JudgeWindowSecondsMarvelous=0.041500
JudgeWindowSecondsMine=0.120000
JudgeWindowSecondsOK=0.250000
JudgeWindowSecondsPerfect=0.04550

adapter:
JudgeWindowSecondsBoo=0.046500
JudgeWindowSecondsGood=0.034900
JudgeWindowSecondsGreat=0.023300
JudgeWindowSecondsMarvelous=0.000100
JudgeWindowSecondsMine=0.120000
JudgeWindowSecondsOK=0.250000
JudgeWindowSecondsPerfect=0.012700

Marvelous und Miss sind beides Grenzwerte, die so eingestellt sind, dass sie nicht auftreten. Wenn ich Marvelous um 0.001 hochsetze und Boo -0.001 runter(also wegen timewindows effektiv 0.5ms), treten erste Marvelousses und Misses auf.
(Timing für Boo) - (Timing für Marvelous) = schwankender Lag

Die Xbox CB hat damit ca. 8ms und der Adapter ca 23.2 ms schwankenden Lag.


Ich hab ein Lied pro Gerät 6 mal durchlaufen lassen, der schwankende Lag ist in 4 Bereiche unterteilt. Bei der Xbox CB ist ein Bereich 2ms groß und bei dem Adapter 5.8ms.
Für die Scores kam diesmal Butterfly Upswing Mix zum Einsatz, aber für den Zweck so verändert, das es nur noch Down-Arrows im Vierteltakt gab.
Ganz oben steht Perfect, unten Boo.

Adapter:

71 | 66 | 68 | 70 | 68 | 71
59 | 62 | 60 | 57 | 65 | 57
68 | 66 | 64 | 67 | 64 | 66
31 | 35 | 37 | 35 | 32 | 35

Adapter mit Echtzeitpriorität:

67 | 71 | 71 | 68 | 67 | 72
62 | 57 | 60 | 59 | 58 | 60
66 | 65 | 64 | 68 | 67 | 67
34 | 36 | 34 | 34 | 37 | 30

Der 1. und 3. Wert kommt häufiger vor als die beiden anderen, ziemlich komisch
Ich seh keinen Unterschied zwischen normal und Echtzeit, scheint also nicht so viel auszusagen.



Xbox CB:

48 | 43 | 40 | 42 | 38 | 40
65 | 66 | 75 | 69 | 69 | 75
60 | 65 | 63 | 66 | 76 | 66
56 | 55 | 51 | 52 | 41 | 48

Xbox CB mit Echtzeitpriorität:

49 | 48 | 50 | 40 | 42 | 41
66 | 62 | 65 | 70 | 73 | 69
62 | 66 | 60 | 63 | 58 | 69
52 | 53 | 54 | 56 | 56 | 50


Hier erkennt man schon eher eine Charakteristik, die beiden Mittelwerte kommen häufiger als die Grenzwerte vor.
Bei dem kleineren Timewindow müsste man eher Unterschiede sehen, wenn man auf Echtzeit stellt, aber auch da ist nichts nennenswertes zu berichten.


Offset:
Die Xbox CB steht ungefähr bei 24.75 ms und der Adapter bei 11.65ms, ergibt einen durchschnittlichen Offset von ca. 13 ms.

Ist eigentlich nicht sehr viel, ich seh als Hauptproblem immernoch den schwankenden Lag. Oder kann man sinnvoll erklären, warum der so hoch ist und dass er nicht vom Adapter ist?


PS:
@USB Patch
Ja es ist ja auch weniger schwammig, zumindest ein bisschen und außerdem ist so ein Effekt bestimmt auch mehr subjektiv zurückzuführen. Man weiß, dass der Adapter jetzt effektiv auf jeden Fall ein Stück besser reagiert, also geht man optimistischer an die Sache ran.
Genauso hab ich den Lag des Adapters subjektiv erstmal auf 60 ms geschätzt.

Anstatt an die X-box-Controllerbox nur einen USB Stecker anzulöten kann man auch ein zweites Kabel anlöten. Dann ist sie für USB und X-Box zu benutzen.

Man kann also sein Equipment an einer technischen Plattform mehr betreiben.

Hier kurz ergänzend die Durchschnittswerte:

Adapter:
71 | 66 | 68 | 70 | 68 | 71 | ~69 Perfects
59 | 62 | 60 | 57 | 65 | 57 | ~60 Greats
68 | 66 | 64 | 67 | 64 | 66 | ~65,83 Goods
31 | 35 | 37 | 35 | 32 | 35 | ~34,16 Boos

Adapter mit Echtzeitpriorität:
67 | 71 | 71 | 68 | 67 | 72 | ~69,3 Perfects
62 | 57 | 60 | 59 | 58 | 60 | ~59,3 Greats
66 | 65 | 64 | 68 | 67 | 67 | ~66,16 Goods
34 | 36 | 34 | 34 | 37 | 30 | ~34,16 Boos

Xbox CB:
48 | 43 | 40 | 42 | 38 | 40 | ~41,83 Perfects
65 | 66 | 75 | 69 | 69 | 75 | ~69,83 Greats
60 | 65 | 63 | 66 | 76 | 66 | ~66 Goods
56 | 55 | 51 | 52 | 41 | 48 | ~50,5 Boos

Xbox CB mit Echtzeitpriorität:
49 | 48 | 50 | 40 | 42 | 41 | ~45 Perfects
66 | 62 | 65 | 70 | 73 | 69 | ~67,5 Greats
62 | 66 | 60 | 63 | 58 | 69 | ~63 Goods
52 | 53 | 54 | 56 | 56 | 50 | ~53,5 Boos

Wie zuerkennen ist, bringt die Echtzeitpriorität für einen Adapter gar nichts (die leichte Verschlechterung hin zu Goods ist bei nur sechs Durchläufen wahrscheinlichkeitsbedingt). Bei der Xbox-CB führt das interessanter Weise zu Extremen: Mehr Perfects und Boos, aber auch das schreibe ich vorerst der Unschärfe zu.

Scorpion hat geschrieben:Die Xbox CB hat damit ca. 8ms und der Adapter ca 23.2 ms schwankenden Lag.

Darin stecken natürlich noch 1ms USB, Xms LPT und wer weis was noch...

Aber jetzt heißt es erstmal wieder grübeln...