Testbericht unter Linux

[rayquaza]

Hinweis: Johannes hat freundlicherweise die Informationen zur Verwendung von Zusi mit Wine aus diesem und weiteren Threads in einem eigenen Posting zusammengefasst und scheint dieses bei Bedarf zu aktualisieren.

--

Ich habe mir mal die Zeit genommen und die Zusi3-Demo einem ausführlichen Test unter Linux unterzogen.
Der Test wurde auf einem Acer Aspire 5730ZG unter der 64-Bit-Version von Ubuntu 10.04 LTS (mit installiertem Wine ) durchgeführt.

Die Installation dauerte weniger als eine Minute und verlief ohne Probleme. Nach dem Programmstart braucht Zusi erstmal einige "Gedenksekunden". Sobald der Cursor im Demo-Info-Fenster anfängt zu blinken, kann man auch auf weiter drücken.
Nun ging es an die Konfiguration: Da ich erwartete, dass Zusi durch die Nicht-Emulation ("WINE is not an emulator") - und dies auch noch am Laptop - deutlich langsamer laufen würde, habe ich zuerst deutlich "vorsichtigere" Grafik-Einstellungen gewählt, als am Windows-PC. Meine erste Konfiguration sah etwa so aus:
- Horizont: ca. 700m
- LOD-Faktor: ~20%
- Darstellung ab LOD 2

Mit dieser Konfiguration ging es auf zur ersten Fahrt. Ich wählte Zug 57566, meinen Lieblingszug in diesem Fahrplan. Nach nur 10 Sekunden erschien der "Szene wird geladen"-Bildschirm, weitere 40 Sekunden später war die Simulation bereit.
Bereits beim Anfahren bemerkte ich, dass die Simulation ungewohnt flüssig läuft. Nach etwas herumprobieren landete ich erstmal bei folgenden Einstellungen:
- Horizont: ca. 1100m
- LOD-Faktor: 50%
- Darstellung ab LOD 1

Die Landschaft sah allerdings recht kantig aus, da mit Wine anscheinend kein Antialiasing möglich ist. Dennoch lies es sich mit diesen Einstellungen bis Altenbeken gut fahren. Dort kam es allerdings zu Einbrüchen der Framerate bis ca. 13fps. Das auf meinem Windows-System vorhandene "Knacksen" im Sound trat nicht auf.
Da mir auf der Fahrt keine Unterschiede mit höheren LOD-Faktoren auffielen, werde ich diesen Wert für weitere Fahrten auf ~40% stellen.
In der Auswertung werden leider nur die Texte (Skalen links und unten und z.B. Zwangsbremsungen) dargestellt - der Verlauf der gefahrenen Geschwindigkeit fehlt.
Bei weiteren Fahrten fiel mir auf, dass Lichtsignale dazu neigen zu flimmern. Die eigentlich dauerhaft leuchtenden Anzeigen (inkl. Zs3 u.Ä.) blinken also wild durcheinander.
Ausserdem ist die Vorschau in der Zugauswahl beim ersten Versuch nicht möglich. Ein Rechtsklick und zwei Linksklicks (mit Abstand) auf den gewünschten Zug sorgen für die korrekte Anzeige.

Bei Zügen die mit der Baureihe 216 gefahren werden stürzt Zusi während oder kurz vor dem "Szene wird geladen"-Bildschirm ab. Getestet habe ich dies bei den Zügen 3541, 5921, 53842 und 841.

Fazit: Ich halte zumindest das noch recht kleine Streckennetz der Demo auf Linux-System für nutzbar.


/edit: Ich wurde eben noch an einen gelegentlich auftretenden Grafik-Bug erinnert. In Altenbeken fehlen (zumindest unter Linux) teilweise Weichen und Signale - nach etwas Standzeit werden sie dann ganz schnell eingebaut:


/e2: Typo ("Wien" -> "Wine") und Zug 841 als getestet hinzugefügt
/e3: Hinweis auf Zusammenfassung wie erbeten ergänzt

[Matthias S.]

Danke für diese Zusammenfassung. Zusi 3 (und mit Einschränkungen auch Nummer 2) ist der einzige Grund für mich, nicht komplett auf Windows zu verzichten.

[Carsten Hölscher]

Wenn Weichen später erscheinen, dann ist Zusi mit dem Laden nicht rechtzeitig nachgekommen.

Danke für die Tests. Screenshots zu den Problemen wären mal ganz interessant, wenn es sich ergeben sollte.

Carsten

[Johannes]

Danke ebenfalls für den Test – er bewegt mich, Zusi 3 auf Linux doch noch nicht ganz aufzugeben … Bei mir funktionieren die Zugauswahl und das Laden der Streckendateien gut, dann kommt der Ladebildschirm („Zusi – der Zugsimulator“) und das Programm friert ein. „strace“ zeigt eine Endlosschleife von Meldungen:

Code: Alles auswählen

futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7e2ad5c0, FUTEX_WAIT_PRIVATE, 0, {5, 0}) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7e2ad5c0, FUTEX_WAIT_PRIVATE, 0, {5, 0}) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7e2ad5c0, FUTEX_WAIT_PRIVATE, 0, {5, 0}) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7e2ad5c0, FUTEX_WAIT_PRIVATE, 0, {5, 0}) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7e2ad5c0, FUTEX_WAKE_PRIVATE, 1) = 0

wobei ich noch nicht herausgefunden habe, worauf die hindeuten (Deadlock?). Werde es aber bei Gelegenheit mit anderen Rechnern noch probieren (der Vollständigkeit halber: der aktuelle ist ein Thinkpad X220 mit Core i5 und Intel-Grafik sowie openSuse 12.1). Zusi 2 läuft auf derselben Konfiguration übrigens anstandslos, ebenso wie Zusi 3 auf demselben Rechner unter Windows.

[rayquaza]

Wenn Weichen später erscheinen, dann ist Zusi mit dem Laden nicht rechtzeitig nachgekommen.

Das habe ich vermutet/befürchtet. Kann man Zusi dazu bringen, das schonmal "vorzuladen"? Wenn's nur Weichen wären, wäre es mir noch relativ egal, aber leider ist auch das Signal für die Zielbremsung betroffen. Letzteres wird anscheinend als letztes geladen.

Danke für die Tests. Screenshots zu den Problemen wären mal ganz interessant, wenn es sich ergeben sollte.

Ich "zerpflücke" mich dann mal:

Nach dem Programmstart braucht Zusi erstmal einige "Gedenksekunden". Sobald der Cursor im Demo-Info-Fenster anfängt zu blinken, kann man auch auf weiter drücken.

Wenn man das Zusi-Fenster wieder in den Vordergrund holt, nachdem man in einer anderen Anwendung etwas gemacht hat (oder eben beim Programmstart) steht die gesamte Bildschirmoberfläche (auch z.B. die Uhr im Panel) für 5sec still. Ich finde es nicht sehr schlimm - während dem Fahren sollte man sich eh nicht ablenken lassen

Die Landschaft sah allerdings recht kantig aus, da mit Wine anscheinend kein Antialiasing möglich ist.

Ich vermute, dass Wine kein Antialiasing unterstützt - wenn dem so ist, kein Zusi-Fehler.

Dort kam es allerdings zu Einbrüchen der Framerate bis ca. 13fps.

Da kann Zusi wohl auch weniger was für - Der Laptop ist ja auch eigentlich nicht dafür gedacht.

Das auf meinem Windows-System vorhandene "Knacksen" im Sound trat nicht auf.

[OT]Dürfte das hier sein - das Makrofon klingt dadurch auch etwas seltsam. (Hat eigentlich schon mal jemand bei der 216 den Motor aus- und wieder angeschalten? Klingt das nur bei mir so seltsam?)[/OT]

In der Auswertung werden leider nur die Texte (Skalen links und unten und z.B. Zwangsbremsungen) dargestellt - der Verlauf der gefahrenen Geschwindigkeit fehlt.

Das hätte ich 'ne halbe Minute früher lesen müssen. Screenshot wird geliefert, wenn ich das nächste mal in Altenbeken bin - voraussichtlich morgen.

Bei weiteren Fahrten fiel mir auf, dass Lichtsignale dazu neigen zu flimmern. Die eigentlich dauerhaft leuchtenden Anzeigen (inkl. Zs3 u.Ä.) blinken also wild durcheinander.

Screenshot wird dabei schwer *gg*. Ich versuch es zu Dokumentieren, wenn ich zu komme. [OT]Wie kann man eigentlich unter Linux (möglichst ohne Zusatzsoftware/-hardware) ein Bildschirmvideo machen?[/OT]

Ausserdem ist die Vorschau in der Zugauswahl beim ersten Versuch nicht möglich. Ein Rechtsklick und zwei Linksklicks (mit Abstand) auf den gewünschten Zug sorgen für die korrekte Anzeige.

Wenn man es weiss, ist das auch nicht schlimm. Manchmal funktioniert es auch normal, ist aber selten.

Bei Zügen die mit der Baureihe 216 gefahren werden stürzt Zusi während oder kurz vor dem "Szene wird geladen"-Bildschirm ab. Getestet habe ich dies bei den Zügen 3541, 5921 und 53842.

Da liefere ich gerne einen Screenshot nach - mal sehen, wer den relevanten Unterschied findet:

/edit: Ich wurde eben noch an einen gelegentlich auftretenden Grafik-Bug erinnert. In Altenbeken fehlen (zumindest unter Linux) teilweise Weichen und Signale - nach etwas Standzeit werden sie dann ganz schnell eingebaut:

Und zum Schluss:

Bei mir funktionieren die Zugauswahl und das Laden der Streckendateien gut, dann kommt der Ladebildschirm („Zusi – der Zugsimulator“) und das Programm friert ein. „strace“ zeigt eine Endlosschleife von Meldungen.

@Johannes: Das hört sich nach dem an, was ich bei Zügen mit einer 216 als Zuglok festgestellt habe. Versuch' mal Zug 57566 oder den Anderen mit 'ner 120.

mfg~ray

[Carsten Hölscher]

Was bietet Zusi denn für Anti-Aliasing-Möglichkeiten an? Da wird ja nur das angeboten, was das System kann (wenn alles korrekt läuft).

Carsten

[Johannes]

Bei mir funktionieren die Zugauswahl und das Laden der Streckendateien gut, dann kommt der Ladebildschirm („Zusi – der Zugsimulator“) und das Programm friert ein. „strace“ zeigt eine Endlosschleife von Meldungen.

@Johannes: Das hört sich nach dem an, was ich bei Zügen mit einer 216 als Zuglok festgestellt habe. Versuch' mal Zug 57566 oder den Anderen mit 'ner 120.

Nein, ich habe gleich den 57566 ausprobiert und auch bei anderen Lokomotiven tritt der Fehler auf. Naja, werde beizeiten weiter suchen

[rayquaza]

Was bietet Zusi denn für Anti-Aliasing-Möglichkeiten an? Da wird ja nur das angeboten, was das System kann (wenn alles korrekt läuft).

Wenn ich das korrekt in Erinnerung habe nennt sich das "-" *gg*
Ich habe inzwischen ein wenig hierzu recherchiert: Unter Wine ist Antialiasing anscheinend tatsächlich standardmässig nicht verfügbar, kann aber (eventuell vielleicht oder so) manuell aktiviert werden.
Quellen: [winehq.org/pipermail], [forum.winehq.org]

Nach einer kurzen Eingewöhnungszeit stört es aber kaum. Die defekte 216 macht mir eher sorgen - Personenverkehr ist mir eigentlich lieber, auch wenn ich neuere Drehstromloks mehr mag.

Ich werde (wenn nicht wieder was dazwischen kommt...) *morgen* die Screenshots nachliefern, weiter rumprobieren und einen Leistungsvergleich Windows Vista (das da immernoch ungenutzt drauf ist - hoffentlich hat jemand kein Pwd...) vs. Ubuntu 10.04 durchführen.

[Reidar]

Also Zusi 3 unter Linux zum Laufen zu kriegen ist mehr oder minder mit Glück verbunden. Auf meinem Gentoo-System läuft es zwar unter vmware mit höchstens 8 fps, die Emulation unter wine klappt jedoch gar nicht (Installation okay, Programmstart auch, aber nach einer Stunde Laden der 3D-Szene habe ich aufgegeben).

Es sei an der Stelle bemerkt, dass beispielsweise Starcraft 2 in der gleichen Konfiguration mit wine flüssig läuft. Kernel 3.0.1 mit wine-1.3.37. Version 1.4 kann ich bei Gelegenheit ja mal testen.

[Johannes]

Also Zusi 3 unter Linux zum Laufen zu kriegen ist mehr oder minder mit Glück verbunden. Auf meinem Gentoo-System läuft es zwar unter vmware mit höchstens 8 fps, die Emulation unter wine klappt jedoch gar nicht (Installation okay, Programmstart auch, aber nach einer Stunde Laden der 3D-Szene habe ich aufgegeben).

Klingt nach demselben Problem, das ich auch habe – du kannst ja mal in ein Terminal

Code: Alles auswählen

strace -p `pidof ZusiSim.exe`

eingeben (auf die ` achten!), während die 3D-Szene am Laden ist. Sollten die gleichen Meldungen wie bei mir oben kommen.

Ich habe es übrigens gerade mit dem just erschienenen Wine 1.4 probiert, leider ohne Erfolg.

[Johannes]

Aha! Bei mir funktioniert es jetzt doch.

Ich habe Zusi 3 zunächst neu installiert, wobei ich als Zielverzeichnis Z:\Zusi3BetaDemo angegeben habe (Z:\ ist ein virtueller Laufwerksbuchstabe in Wine, der auf das Verzeichnis /mnt/zusi zeigt, unter dem wiederum meine Zusi-Partition gemountet ist). Das Datenverzeichnis habe ich auf „Standard“ gelassen, also effektiv auf ~/.wine/dosdevices/c:/windows/profiles/All Users/Dokumente/Zusi3Demo. Wiederum fror das Programm beim Laden ein.

Dann habe ich Zusi 3 nochmals neu installiert, wobei ich diesmal als Zielverzeichnis Z:\Zusi3\BetaDemo und als Datenverzeichnis Z:\Zusi3\Daten gewählt habe. Jetzt funktionierte es auf einmal wunderbar. Womöglich liegt es also an der Wahl des Datenverzeichnisses?

Allerdings kann ich ebenfalls keine Fahrten mit der 216 unternehmen, das Programm friert beim Laden ein. Ein klein wenig untersucht habe ich das Problem schon, so scheint die letzte geladene Datei vor dem Absturz immer die Datei „RollingStock/Deutschland/Epoche3/Dieselloks/BRD/V160_Familie/Gemeinsame_Daten/Sounds/Luftpresser_74671_588638.wav“ zu sein und der Inhalt der Datei spielt anscheinend keine Rolle (habe sie probehalber durch eine andere Datei ersetzt und sogar gelöscht).

Daraufhin habe ich nochmals mit dem alten Datenverzeichnis neu installiert, um zu sehen, was hier die letzte geladene Datei vor dem Einfrieren war. Ausprobiert habe ich den 57566 mit Baureihe 120, die letzte geladene Datei war „RollingStock/Deutschland/Epoche4/Elektroloks/BRD/120/Sounds/120_Luftpresser.wav“. Dann habe ich den 51610 mit Baureihe 110 ausprobiert, die letzte geladene Datei war „RollingStock/Deutschland/Epoche3/Elektroloks/BRD/Einheitsloks/Sounds/DB_110/110_Luftpresser.wav“.

Das hat ja immerhin schon ein gewisses Muster, wobei es natürlich gut sein kann, dass die Luftpresser-Datei rein gar nichts mit dem Absturz zu tun hat, sondern z.B. nur die letzte geladene Datei ist, bevor sich das Programm anderen Aufgaben zuwendet, bei denen es dann einfriert.

[F. Schn.]

Wenn du das Meldungsfenster öffnest (Hilfe => Meldungsfenster anzeigen) kannst du dort Rechte Maustaste => Meldungen für Fehlersuche aktivieren. Bei mir (unter Windows) ist der Luftpresser die erste Datei (nach einigen Initialisierungswerten) überhaupt.

Die nächste Datei sei angeblich

Code: Alles auswählen

Lade Sound RollingStock\Deutschland\Epoche3\Dieselloks\BRD\V160_Familie\Gemeinsame_Daten\Sounds\Hintergrund 217.wav

Ich lese hier ein Leerzeichen. Das könnte eventuell dafür verantwortlich sein.

Edit: ~/.wine/dosdevices/c:/windows/profiles/All Users/Dokumente/Zusi3Demo hat in All Users ebenfalls ein Leerzeichen. Zusammen mit der Beobachtung, das der Fahrplaneditor (Linux + Mono) auch Probleme machte, wenn sein Dateiname Leerzeichen enthielt...

[rayquaza]

Edit: ~/.wine/dosdevices/c:/windows/profiles/All Users/Dokumente/Zusi3Demo hat in All Users ebenfalls ein Leerzeichen. Zusammen mit der Beobachtung, das der Fahrplaneditor (Linux + Mono) auch Probleme machte, wenn sein Dateiname Leerzeichen enthielt...

Da Leerzeichen in Dateinnamen generell böse sind (enwiki), gehe ich davon aus, dass dies die Fehlerquelle ist. Ich schlage vor, das Problem innerhalb Zusis zu lösen, sofern dies möglich ist. Alternativ könnte im Handbuch ein Satz wie "Leerzeichen in Dateipfaden sind unzulässig" eingefügt werden. Ich bin aber noch nicht lange genug hier dabei um einzuschätzen, ob sich alle an solche Regeln halten würden...

Das Flimmern der Lichtsignale habe ich inzwischen vom Bildschirm abgefilmt. Hierbei ist mir ein etwas seltsames Verhalten des Zugkraftstellers aufgefallen: Wenn man den Zugkraftsteller auf 0 stellt, vor dem Wiederaufschalten aber nicht wartet, bis der Zugkraftsollzeiger wieder auf 0 ist, wird keine Zugkraft freigegeben (der Sollzeiger geht aber auf Maximum). Die Videos stehen bis Sonntagabend hier (depositfiles.com, 7z-File mit 3 3GPP-Videodateien, 37,4MB) zum Download bereit. Dateikennwort ist "Zusi3". An dieser Stelle möchte ich mich bei der Weiche im letzten Video entschuldigen*gg*. Der Zug ist aber noch kurz vor dem Grenzzeichen der Weiche hinter dem Asig zum Halten gekommen - das Signal wurde ja erst danach eingebaut

Zum Performancevergleich Vista vs. Ubuntu: Unter Vista erreiche ich bei vergleichbaren Einstellungen vergleichbare Frameraten - Dass die Weichen und Signale in HA erst zu spät nachladen tritt auch unter Vista auf.

Zum Schluss möchte ich noch den versprochenen Screenshot der Auswertung nachliefern:


Ich hoffe ich habe nichts und niemanden vergessen. Falls doch bitte melden.

/e: Hoster geändert - Bisheriger Link

mfg~ray

[Johannes]

Hallo!

Erst mal vielen Dank für den Tipp mit dem Meldungsfenster! Leider wird das bei mir (unter Linux) vor dem Einfrieren nicht schnell genug aktualisiert, sodass ich deine Meldung nicht nachvollziehen konnte. Ich glaub’s dir aber

Die nächste Datei sei angeblich

Code: Alles auswählen

Lade Sound RollingStock\Deutschland\Epoche3\Dieselloks\BRD\V160_Familie\Gemeinsame_Daten\Sounds\Hintergrund 217.wav

Ich lese hier ein Leerzeichen. Das könnte eventuell dafür verantwortlich sein.

Autsch! Leerzeichen in Dateinamen sollte eigentlich das erste sein, worauf man bei solch einem Symptom kommen sollte … ich fühle mich jetzt offiziell dumm Das klingt tatsächlich wie die logischste Erklärung. Allerdings ist es interessant, dass in den Logs von „strace“ (protokolliert die Systemaufrufe eines Programms inklusive Parametern) nirgendwo das Wort „Hintergrund“ auftaucht.

Ich habe also die Datei „Hintergrund 217.wav“ nach „Hintergrund_217.wav“ umbenannt und in der ZusiSim.exe mit einem Hexeditor den Dateinamen in den XML-Daten angepasst. Leider hat das das Problem nicht gelöst, das Programm friert immer noch ein. Es wird dabei durchaus die korrekte Datei (mit Unterstrich) versucht zu laden, wie ich unter Windows mit dem Meldungsfenster erkennen konnte.

Testhalber habe ich einmal alle Dateien unter „RollingStock“, die ein Leerzeichen enthalten, umbenannt und die Referenzen in ZusiSim.exe angepasst. Geholfen hat das leider auch nichts. Also ist wohl Weitersuchen (in dieser Richtung) angesagt …

[Dennis Bork]

Hallo Ray,

nur mal so in den Raum geworfen: Kennst Du http://www.reactos.org/en/index.html" target="_blank?

Vielleicht hilft das bei einigen der WINE-eigenen Probleme?

[rayquaza]

nur mal so in den Raum geworfen: Kennst Du http://www.reactos.org/en/index.html" target="_blank?

Ich hab' schonmal von gehört. Allerdings geht das leider an meinen Wünschen vorbei, denn

es handelt sich nicht um ein Linux-basiertes System und hat keine Gemeinsamkeiten mit der Unix-Architektur.

Es geht mir dabei auch nicht darum, dass ich keine der überteuerten Windows-Lizenzen erwerben will - mir ist Linux einfach lieber.

Vielleicht hilft das bei einigen der WINE-eigenen Probleme?

Das bezweifle ich etwas, denn

ReactOS arbeitet sehr eng mit WINE zusammen, und beide Projekte profitieren voneinander. Mehrere Entwickler sowohl im WINE als auch im ReactOS-Projekt arbeiten an der Kompatibilität beider Projekte.

Das ReactOS-Team geht zwar laut deren FAQ davon aus, dass ReactOS

das Potential einer bedeutend höheren Kompatibilität [hat] – besonders für Microsoft Windows Treiber mit denen sich WINE nicht befasst.

Dies dürfte aber imo eher sehr Systemnahes wie Treiber betreffen.

Bei Zügen die mit der Baureihe 216 gefahren werden stürzt Zusi während oder kurz vor dem "Szene wird geladen"-Bildschirm ab. Getestet habe ich dies bei den Zügen 3541, 5921 und 53842.

Da liefere ich gerne einen Screenshot nach - mal sehen, wer den relevanten Unterschied findet:

Ich wollte noch das kleine Rätsel auflösen: Die graue Leiste im unteren Bereich des Fensters ist normalerweise auch weiss und dort sollten eigentlich die geladenen Dateien erscheinen.

[Chrigu]

Hallo zusammen,

Ich habe heute Abend auch mal die Zusi 3 Demo unter Linux ausprobiert.

SW: Ubuntu 11.10 64bit, Wine 1.4
HW: CPU Intel Core2 6600 @2.4GHz, GraKa Nvidia GeForce 7950GT

Feststellungen:
- Installation nach C:\Zusi3Demo (Prog & Anwenderdaten) hat funktioniert
- Alle Züge ausser jene mit BR216 laden erfolgreich (wie bereits von anderen festgestellt)
- Anti-Aliasing funktioniert, die Einstellung stehen in der Zusi Konfig zur Verfügung und zeigen Wirkung
- Framerate liegt beim D841 stehend in Altenbeken bei rund 14 FPS (Auf dem gleichen Rechner unter Win7 werden dort gegen rund 35 FPS erzielt)
- Grafikprobleme wie zu spät nachladende Objekte konnte ich keine entdecken
- Problem beim Diagramm in der Auswertung (siehe Beitrag von Ray)
- Weder Vollbild (Landschaft lädt nicht) noch DirectX Vollbild (Landschaft lädt, Simulation lässt sich aber nicht bedienen) Modi funktionieren
- Verändern von WineD3D Parametern zeigten keine Auswirkungen auf die erzielte Framerate (weder negativ noch positiv)

Ich habe nur kurz angetestet, daher auch keine ausführlichen Analysen, sondern nur Feststellungen. Falls konkrete Fragen bestehen, probiere ich gerne noch was aus.

Gruss
Chrigu

[rayquaza]

Hallo Chrigu,

Vielen Dank für deinen Bericht.

- Alle Züge ausser jene mit BR216 laden erfolgreich (wie bereits von anderen festgestellt)

Bei mir funktionieren nur die beiden Züge mit Tfz BR120. Hier sollten wir (=alle anwesenden Linux-User und Carsten) vielleicht noch weiter nachforschen.

- Anti-Aliasing funktioniert, die Einstellung stehen in der Zusi Konfig zur Verfügung und zeigen Wirkung

Hattest du zuvor an den WINE-Einstellungen etwas geändert (z.B. für andere Spiele)?
Nachtrag: Nach setzen des Registry-Wertes HKCU/Software/Wine/Direct3D->Multisampling auf "enabled" ist auch bei mir AA ohne (spürbare) Framerateverschlechterungen verfügbar.

- Framerate liegt beim D841 stehend in Altenbeken bei rund 14 FPS (Auf dem gleichen Rechner unter Win7 werden dort gegen rund 35 FPS erzielt)

Da der offizielle Test bei mir nicht möglich ist nehme ich mal ganz direkt Bezug auf den letzten Abschnitt deines Postings und bitte um folgenden Versuch in Anlehnung an den offiziellen Speed-Test (zur Vergleichbarkeit bitte unter beiden OS):

Code: Alles auswählen

- Zusi starten
- Menü->Einstellungen: "Standardwerte für alle Karten" drücken
- Menü->Einstellungen/Grafikinitialisierung: "Im eigenen Fenster"
- Menü->Einstellungen/Grafik+Sound: "fps-Anzeige" aktivieren und "Framebremse" deaktivieren"
- Menü->Konfiguration: Auf 1024x768
- Dg54714 wählen
- Sofort eine Schnellbremsung durchführen
- F4 drücken, warten, bis Zug aufgegleist ist
- F7 drücken zum Ausblenden des Buchfahrplans
- F5 drücken zum Ausblenden des Führerstands, warten bis sich die fps eingependelt hat

Ich komme dabei unter Vista auf 7-9 fps und unter Ubuntu auf 9 fps (also sehr ähnliche Werte).

- Grafikprobleme wie zu spät nachladende Objekte konnte ich keine entdecken

Das liegt bei mir nahezu sicher an der Leistung des Laptops, da es auch unter Vista auftritt.

- Weder Vollbild (Landschaft lädt nicht) noch DirectX Vollbild (Landschaft lädt, Simulation lässt sich aber nicht bedienen) Modi funktionieren

Das hatte ich noch nicht getestet. Eventuell versuche ich es in den nächsten Tagen mal und berichte.

Nachtrag: Beim Versuch in den Vollbildmodus zu schalten verschwand das Zusi-Fenster komplett. Selbst eine Neuinstallation Zusis blieb erfolglos, ich musste den Registry-Schlüssel manuell löschen!

- Verändern von WineD3D Parametern zeigten keine Auswirkungen auf die erzielte Framerate (weder negativ noch positiv)

Welche Parameter genau meinst du?



OT: Gibt es in der Zusi3BetaDemo eigentlich irgendwo Ersatzsignale, Befehle und/oder Rangierfahrten die auch genutzt werden?

@all: Weitere Berichte würden mich freuen, auch wenn nur bereits genanntes bestätigt wird. Bisher war bei jedem zumindest etwas unterschiedlich.

mfg~ray

/e: Typo
/e2: Nachtrag
/e3: Typo, die zweite + Edit-Log vervollständigt

[Reidar]

Gerade eben nochmal probiert (diesmal mit Wine 1.4) und zumindest die 120er läuft, die Züge mit der 216 hängen im Laden der 3D-Szene. Von AA bis AF wird mir alles angeboten für meine GTX 560 und auch prima unterstützt (keine Ladeverzögerung etc), einzig interessant sind die Performanceeinbrüche im Führerstandsmodus. Wenn der Horizont > 500m eingestellt ist, komme ich nicht mehr über 24 fps hinaus, alles darunter (oder auch im Tunnel) läuft prima flüssig. Interessant ist dies deswegen, da dieses Phänomen nicht bei der Außenansicht auftritt.

[Chrigu]

Hattest du zuvor an den WINE-Einstellungen etwas geändert (z.B. für andere Spiele)?
Nachtrag: Nach setzen des Regestry-Wertes HKCU/Software/Wine/Direct3D->Multisampling auf "enabled" ist auch bei mir AA ohne (spürbare) Framrateverschlechterungen verfügbar.

Nein, HKCU/Software/Wine/Direct3D war "jungfräulich" - Der Konfigurationsdialog von Zusi 3 bot mir AA Optionen zur Auswahl von 'aus' bis '16x'. Default war auf '8x'.

Da der offizielle Test bei mir nicht möglich ist nehme ich mal ganz direkt Bezug auf den letzten Abschnitt deines Postings und bitte um folgenden Versuch in Anlehnung an den offiziellen Speed-Test (zur Vergleichbarkeit bitte unter beiden OS):

Code: Alles auswählen

- Zusi starten
- Menü->Einstellungen: "Standardwerte für alle Karten" drücken
- Menü->Einstellungen/Grafikinitialisierung: "Im eigenen Fenster"
- Menü->Einstellungen/Grafik+Sound: "fps-Anzeige" aktivieren und "Framebremse" deaktivieren"
- Menü->Konfiguration: Auf 1024x768
- Dg54714 wählen
- Sofort eine Schnellbremsung durchführen
- F4 drücken, warten, bis Zug aufgegleist ist
- F7 drücken zum Ausblenden des Buchfahrplans
- F5 drücken zum Ausblenden des Führerstands, warten bis sich die fps eingependelt hat

Ich komme dabei unter Vista auf 7-9 fps und unter Ubuntu auf 9 fps (also sehr ähnliche Werte).

Dieser Test führt zu folgenden Werten:

Code: Alles auswählen

Ubuntu 11.10 64bit/Wine 1.4: 13 fps
Win7 64bit in VM:            5 fps (VirtualBox, nutzt auch WineD3D für die Direct3D Emulation)
Win7 64bit Native:           31 fps

Also bei mir unter Linux eine dreimal tiefere Framerate als unter Windows 7.

Nachtrag: Beim Versuch in den Vollbildmodus zu schalten verschwand das Zusi-Fenster komplett. Selbst eine Neuinstallation Zusis blieb erfolglos, ich musste den Registry-Schlüssel manuell löschen!

Dieses Verhalten kann ich bestätigen.

Welche Parameter genau meinst du?

Folgende Wine Parameter habe ich jeweils einzeln verändert (ohne mir die Mühe zu machen, nachzulesen wozu sie sind). Bezeichnungen gemäss "Wintetricks", default Wert mit * versehen.

Code: Alles auswählen

glsl = enabled* / disabled ; Disable glsl shaders, use arb shaders (faster, but sometimes breaks)
orm = fbo* / backbuffer ; OffScreenRenderingMode (Mit backbuffer ist AA nicht verfügbar)
vsm = hardware ; Set VertexShaderMode to hardware (Ein Defaultwert fehlt in Winetricks, wahrscheinlich software ;-) )

Gerade eben nochmal probiert (diesmal mit Wine 1.4) und zumindest die 120er läuft, die Züge mit der 216 hängen im Laden der 3D-Szene. Von AA bis AF wird mir alles angeboten für meine GTX 560 und auch prima unterstützt (keine Ladeverzögerung etc), einzig interessant sind die Performanceeinbrüche im Führerstandsmodus. Wenn der Horizont > 500m eingestellt ist, komme ich nicht mehr über 24 fps hinaus, alles darunter (oder auch im Tunnel) läuft prima flüssig. Interessant ist dies deswegen, da dieses Phänomen nicht bei der Außenansicht auftritt.

Dieses Verhalten kann ich bestätigen und zwar sowohl unter Linux wie unter Windows 7 (Gleiche Testkonditionen wie oben).

Ubtuntu 11.10:

Code: Alles auswählen

Horizont      500m   1700m
FS, mit Fst   33fps  13fps
FS, ohne Fst  39fps  10fps
Aussen        31fps  30fps

Windows 7

Code: Alles auswählen

Horizont      500m   1700m
FS, mit Fst   87fps  24fps
FS, ohne Fst  92fps  31fps
Aussen        104fps 87fps

Bei Aussensicht gibt es keine wesentlichen Unterschiede in der Framerate bei Horizonten von 500m und 1700m. In der Führerstandssicht (FS) fällt die Framerate bei einem Horizont von 1700m um ca. Faktor 3 gegenüber der Aussensicht ab, bei 500m bleibt sie mehr oder minder stabil. Dieser Effekt hat aber offenbar nichts mit dem Betriebsssystem zu tun.

Gruss
Chrigu