Vorankündigung Zusi 3.5
- Michael_Poschmann
- Beiträge: 19881
- Registriert: 05.11.2001 15:11:18
- Aktuelle Projekte: Modul Menden (Sauerland)
- Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)
Re: Vorankündigung Zusi 3.5
Das sind aber dann Rechner, bei denen regelmäßiges Ausschlacken und Auswaschen des Kessels zu den Bedienhandlungen gehören.
Grüße
Michael
Grüße
Michael
- Jens Haupert
- Beiträge: 4920
- Registriert: 23.03.2004 14:44:34
- Aktuelle Projekte: http://www.zusidisplay.de
- Wohnort: Berlin
- Kontaktdaten:
Re: Vorankündigung Zusi 3.5
Seit der ZD-Integration (also seit über 2,5 Jahren) braucht man zwingend Windows 7 oder neuer. Wer noch mit XP unterwegs ist, muss ja auf einem alten Stand festhängen. Der wird das Update auf 3.5 dann wohl auch nicht machen.F(R)S-Bauer hat geschrieben: ↑28.09.2021 15:26:26 Hallo Jens,
Du hast recht oder auch nicht. Die Anforderungen sind W7, aber ich meine das war mal XP. Aber ich wette einige fahren noch auf XP mit altem StandJens Haupert hat geschrieben: ↑28.09.2021 08:55:06 ...
das kann eigentlich nicht sein, da ZD nicht mehr auf PCs mit Win XP oder Vista startet.
Grüße
Jens
-
- Beiträge: 6294
- Registriert: 09.11.2002 02:00:47
Re: Vorankündigung Zusi 3.5
Hmmm,
braucht der Simulator dann zwingen 7 wen ich auf ZD Verzichte und die entsprechenden Führerstände nicht nutze?
Klar, bei ZD knallt es, aber wenn Carsten noch auf XP entwickelt...
Gruß
Ralf
braucht der Simulator dann zwingen 7 wen ich auf ZD Verzichte und die entsprechenden Führerstände nicht nutze?
Klar, bei ZD knallt es, aber wenn Carsten noch auf XP entwickelt...
Gruß
Ralf
Re: Vorankündigung Zusi 3.5
Windows XP ist bald 20 Jahre alt. Irgendwann wird der Aufwand, mehrere Ebenen der Rückwärtskompatibilität zu erhalten doch einfach zu groß. Schließlich steigt die Anzahl der Betriebssysteme und Konfigurationen, die für jede neue Version getestet werden müssen sonst immer weiter an. Demnächst erscheint Windows 11, wozu dann wiederum eine Aufwärtskompatibilität bestehen muss. Noch komplizierter würde es, wenn *zusätzlich* das ganze dann noch in 32- und 64-Bit getestet werden müsste. Das ist doch alles Zeit, die nicht mehr für die Weiterentwicklung von Zusi aufgewendet werden kann. Deshalb lasst Windows XP doch in Frieden sterben. Wer es immer noch benutzen möchte wird eh über kurz oder lang, wie Carsten, vor das Problem der nicht mehr verfügbaren Hardware gestellt werden.
Ich würde mich des Weiteren der Meinung anschließen, nur noch für die 64-Bit Plattform zu entwickeln, aus den o.g. Gründen.
Ich würde mich des Weiteren der Meinung anschließen, nur noch für die 64-Bit Plattform zu entwickeln, aus den o.g. Gründen.
Grüße,
Thomas (eh. ElektrikTrick)
Thomas (eh. ElektrikTrick)
Re: Vorankündigung Zusi 3.5
Bei ZusiDisplay schmerzt der Verlust von Windows XP immer noch. Aber für den Simulator und die Editoren kenne ich kein 32-bit-System, das noch Leistungsfähig genug für Zusi ist.
Aber ich schließe mich Johannes an: Bitte nicht zu hohe Erwartungen an die 64bit-Umstellung. Der Kompiler wird hoffentlich etwas mehr aus modernen Prozessor-Instruktionen machen können, aber ansonsten haben wir derzeit keinen Adressraummangel (außer im Gleisplaneditor). Auch setzt Carsten so weit ich das einschätze bereits jetzt Leistungsfähige Strukturen ein (die Streckenelement- und Register-Umnummerierung riecht z.B. nach Array-Zugriffen). Verbesserungen sind höchstens Punktuell zu erhoffen (denkbar wäre z.B. das Laden von Dateien).
Aber ich schließe mich Johannes an: Bitte nicht zu hohe Erwartungen an die 64bit-Umstellung. Der Kompiler wird hoffentlich etwas mehr aus modernen Prozessor-Instruktionen machen können, aber ansonsten haben wir derzeit keinen Adressraummangel (außer im Gleisplaneditor). Auch setzt Carsten so weit ich das einschätze bereits jetzt Leistungsfähige Strukturen ein (die Streckenelement- und Register-Umnummerierung riecht z.B. nach Array-Zugriffen). Verbesserungen sind höchstens Punktuell zu erhoffen (denkbar wäre z.B. das Laden von Dateien).
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
Re: Vorankündigung Zusi 3.5
Klar, für 60fps in Maschen zur Hauptverkehrszeit wirds sicher nicht reichen. Aber manchmal weiß man ja nicht, was sich Computer so denken, und wenn am Ende zufällig hier und da fünf fps mehr rausspringen, dann wäre mir das schon genug
Re: Vorankündigung Zusi 3.5
Was wird sich für wine-Nutzer ändern?
Re: Vorankündigung Zusi 3.5
Wenn es um eine Verbesserung der Performance geht, kommt man normalerweise um die Nutzung eines Profilers nicht herum. Man stochert sonst nur im Dunkeln und versucht zu raten, wo nun die Rechenzeit drauf geht. Das erstmal als Disclaimer.
Als ich Zusi aber vor längerer Zeit in RenderDoc laufen haben lasse (welches die einzelnen Draw Calls für Debugzwecke protokolliert, wobei diese in meinem Fall vorher durch eine DirectX->Vulkan-Übersetzung mittels dxvk gelaufen sind – da bin ich nicht ganz sicher, ob es dadurch zu Verzerrungen kam) hatte ich allerdings nicht den Eindruck, dass die Szene in einer optimalen Reihenfolge gezeichnet wird. Idealerweise werden Zustandsänderungen wie "nächstes Objekt mit anderer Textur zeichnen" möglichst selten vorgenommen, d.h. alle Objekte mit der gleichen Textur werden idealerweise direkt nacheinander gezeichnet. Soweit ich mich erinnere war das nicht der Fall, sondern es wurde mal ein Busch gezeichnet, dann ein Auto, dann wieder ein Busch, dann ein anderer Busch, dann wieder der vorherige Buschtyp, usw. wild durcheinander.
Generell waren es sehr viele sehr "kleine" draw calls mit z.B. nur 36 Vertices für einen Busch, was eine Grafikkarte mit einem halben kleinen Finger vor dem Frühstück erledigt, aber trotzdem führt jeder noch so kleine draw call zu einer CPU-Belastung (falls es seit dem letzten draw call eine neue Textur gab wohl auch durchaus signifkant). Hier könnte man vielleicht direkt alle Büsche eines Buschtyps mit nur einem einzigen instanced draw call erledigen, danach alle Bäume eines Typs mit dem nächsten instanced draw call, usw – oder irgendwie anders mehrere draw calls in einen zusammenfassen. Damit der ganze CPU-Aufwand nicht nur für 36 Vertizes erfolgt. Sonst schläft eben wie momentan die GPU praktisch ein, die mit viel größeren Vertexzahlen auch problemlos umgehen könnte, während die CPU dauerbeschäftigt damit ist, sehr viele Anweisungen für "Kleinstaufträge" einen nach dem anderen zur GPU zu schicken.
Vielleicht ist da also schon noch "Potential zu heben", wenn man die teils wirklich vielen Hundert draw calls pro Frame durch Instancing oder "verschmelzen" reduzieren kann, aber wie viel solche Optimierungen bei den FPS dann wirklich bringen kann ich schwer sagen. Vielleicht ist es die Mühe auch nicht wert, falls woanders für jeden Frame deutlich mehr Zeit benötigt wird und man besser erstmal dort nach Optimierungsmöglichkeiten sucht.
Als ich Zusi aber vor längerer Zeit in RenderDoc laufen haben lasse (welches die einzelnen Draw Calls für Debugzwecke protokolliert, wobei diese in meinem Fall vorher durch eine DirectX->Vulkan-Übersetzung mittels dxvk gelaufen sind – da bin ich nicht ganz sicher, ob es dadurch zu Verzerrungen kam) hatte ich allerdings nicht den Eindruck, dass die Szene in einer optimalen Reihenfolge gezeichnet wird. Idealerweise werden Zustandsänderungen wie "nächstes Objekt mit anderer Textur zeichnen" möglichst selten vorgenommen, d.h. alle Objekte mit der gleichen Textur werden idealerweise direkt nacheinander gezeichnet. Soweit ich mich erinnere war das nicht der Fall, sondern es wurde mal ein Busch gezeichnet, dann ein Auto, dann wieder ein Busch, dann ein anderer Busch, dann wieder der vorherige Buschtyp, usw. wild durcheinander.
Generell waren es sehr viele sehr "kleine" draw calls mit z.B. nur 36 Vertices für einen Busch, was eine Grafikkarte mit einem halben kleinen Finger vor dem Frühstück erledigt, aber trotzdem führt jeder noch so kleine draw call zu einer CPU-Belastung (falls es seit dem letzten draw call eine neue Textur gab wohl auch durchaus signifkant). Hier könnte man vielleicht direkt alle Büsche eines Buschtyps mit nur einem einzigen instanced draw call erledigen, danach alle Bäume eines Typs mit dem nächsten instanced draw call, usw – oder irgendwie anders mehrere draw calls in einen zusammenfassen. Damit der ganze CPU-Aufwand nicht nur für 36 Vertizes erfolgt. Sonst schläft eben wie momentan die GPU praktisch ein, die mit viel größeren Vertexzahlen auch problemlos umgehen könnte, während die CPU dauerbeschäftigt damit ist, sehr viele Anweisungen für "Kleinstaufträge" einen nach dem anderen zur GPU zu schicken.
Vielleicht ist da also schon noch "Potential zu heben", wenn man die teils wirklich vielen Hundert draw calls pro Frame durch Instancing oder "verschmelzen" reduzieren kann, aber wie viel solche Optimierungen bei den FPS dann wirklich bringen kann ich schwer sagen. Vielleicht ist es die Mühe auch nicht wert, falls woanders für jeden Frame deutlich mehr Zeit benötigt wird und man besser erstmal dort nach Optimierungsmöglichkeiten sucht.
- Carsten Hölscher
- Administrator
- Beiträge: 33450
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Vorankündigung Zusi 3.5
Das bringt bestenfalls minimale Verbesserungen.
Man kann die Zeichenreihenfolge auch nicht beliebig machen, gibt sonst Darstellungsfehler.
Ein Sinn der 32 bit-Versionen können dlls sein, die es nicht für 64 bit gibt, z.B. die Draht-dll von Steven.
Carsten
Man kann die Zeichenreihenfolge auch nicht beliebig machen, gibt sonst Darstellungsfehler.
Ein Sinn der 32 bit-Versionen können dlls sein, die es nicht für 64 bit gibt, z.B. die Draht-dll von Steven.
Carsten
-
- Beiträge: 6294
- Registriert: 09.11.2002 02:00:47
Re: Vorankündigung Zusi 3.5
Das ist ein möglicher Weg, und sicher der Einfachste.
Wenn es die DLL so gar nicht in 64Bit geben wird, bleibt auch noch der Weg: https://docs.microsoft.com/en-us/window ... perability
Gruß
Ralf
Wenn es die DLL so gar nicht in 64Bit geben wird, bleibt auch noch der Weg: https://docs.microsoft.com/en-us/window ... perability
Gruß
Ralf
- Max Senft
- Administrator
- Beiträge: 3004
- Registriert: 04.11.2001 14:01:40
- Aktuelle Projekte: Dies und das
- Wohnort: Blieskastel, Saarland, Deutschland
- Kontaktdaten:
Re: Vorankündigung Zusi 3.5
Hi.
Wenn sich eine 32bit Version nicht automatisch aufgrund von Projekt-/Compilier-Parametern erzeugen lässt und/oder es im professionellen Bereich keinen Bedarf gibt, würde ich eine 32bit Version nicht weiter pflegen/anbieten.
Gruß
Max
Aber auch das sollte sich ja eigentlich ohne größere Probleme auf 64bit umstellen lassen? Steven war allerdings schon lange nicht mehr hier im Forum online. Der Quellcode ist nicht irgendwo auf Github o.ä. verfügbar?Carsten Hölscher hat geschrieben: ↑29.09.2021 00:00:49 Ein Sinn der 32 bit-Versionen können dlls sein, die es nicht für 64 bit gibt, z.B. die Draht-dll von Steven.
Wenn sich eine 32bit Version nicht automatisch aufgrund von Projekt-/Compilier-Parametern erzeugen lässt und/oder es im professionellen Bereich keinen Bedarf gibt, würde ich eine 32bit Version nicht weiter pflegen/anbieten.
Gruß
Max
Administrator, Programmierer, Ansprechpartner bei Problemen mit dem Board
-
- Beiträge: 8975
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Vorankündigung Zusi 3.5
Sollte das ernsthaft ein Problem werden, dann wird das Katenoiden-Ding eben kurzfristig neu implementiert. Ein Algorithmus für ein durchhängendes Seil ist ohnehin in jeder Fahrleitungs-DLL enthalten. Dort dann das drumherumzubauen, was die Katenoiden-DLL kann, ist grundsätzlich nicht weiter schwierig.
Mein Youtube-Kanal: youtube.com/echoray1
- Michael_Poschmann
- Beiträge: 19881
- Registriert: 05.11.2001 15:11:18
- Aktuelle Projekte: Modul Menden (Sauerland)
- Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)
Re: Vorankündigung Zusi 3.5
Bitte einfach mal Steven kontaktieren, Downunder ist ja nicht aus der Welt. Das Problemchen lässt sich bestimmt lösen.
Grüße
Michael
Grüße
Michael
- Michael Springer
- Beiträge: 2932
- Registriert: 24.06.2002 16:22:44
- Wohnort: Schwäbisch Gmünd
Re: Vorankündigung Zusi 3.5
Das stimmt, selbst ich habe es schon geschafft, Steven persönlich kennenzulernen...Downunder ist ja nicht aus der Welt.
Re: Vorankündigung Zusi 3.5
(OT: Irgendwie fehlt zum kennen lernen momentan das Zusi-Treffen. Da gab es die letzten zwei Jahre aus irgend einem Grund eine kleine Auszeit...)
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
- Carsten Hölscher
- Administrator
- Beiträge: 33450
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Vorankündigung Zusi 3.5
Es hat gestern die erste 64bit-Fahrt stattgefunden. Den historischen Moment hab ich festgehalten, die V100 hatte die Ehre:
Wie man sieht, fehlen noch die schwarzen Balken am Rand, da schlägt wohl noch irgendwas fehl. Da ich alles auf die Delphi-offiziellen DirectX-Schnittstellen umbaue und es da kleinere Unterschiede zu früher gibt, können solche Sachen noch vorkommen. Aber die eigentliche Grafik inkl. Sound scheint es jetzt zu tun.
Carsten
Wie man sieht, fehlen noch die schwarzen Balken am Rand, da schlägt wohl noch irgendwas fehl. Da ich alles auf die Delphi-offiziellen DirectX-Schnittstellen umbaue und es da kleinere Unterschiede zu früher gibt, können solche Sachen noch vorkommen. Aber die eigentliche Grafik inkl. Sound scheint es jetzt zu tun.
Carsten
-
- Beiträge: 6294
- Registriert: 09.11.2002 02:00:47
Re: Vorankündigung Zusi 3.5
Hallo Carsten,
es wird
Da ich vermute, dass du es geschrieben hättest und es auch zu früh ist, es hat wahrscheinlich keine drastische Performance-Steigerung/Senkung gegeben, sondern es hat sich im erwarteten Rahmen gehalten bzw. war nicht irgendwie direkt auffällig. Weswegen ich frage, ich habe Fälle erlebt, wo die 64Bit Version erstmal halb so schnell war.
Gruß
Ralf
es wird
Da ich vermute, dass du es geschrieben hättest und es auch zu früh ist, es hat wahrscheinlich keine drastische Performance-Steigerung/Senkung gegeben, sondern es hat sich im erwarteten Rahmen gehalten bzw. war nicht irgendwie direkt auffällig. Weswegen ich frage, ich habe Fälle erlebt, wo die 64Bit Version erstmal halb so schnell war.
Gruß
Ralf
- Carsten Hölscher
- Administrator
- Beiträge: 33450
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Vorankündigung Zusi 3.5
Das steht noch aus, jetzt wird erstmal getestet, ob Pipe und LAN schon so wollen wie sie sollen. Durch die Umstellung auf Unicode ist evtl. Anpassungsbedarf gegeben.
Carsten
Carsten
Re: Vorankündigung Zusi 3.5
Ist das unumgänglich?Carsten Hölscher hat geschrieben: ↑19.01.2022 21:02:40 Durch die Umstellung auf Unicode ist evtl. Anpassungsbedarf gegeben.
Bisher (Zusi < 3.5) ist es ja Windows-1252 (8 Bit, feste Länge) und hinreichend für fast alle Bezeichnungen.
Windows und Delphi (vermutlich) arbeiten mit UCS-2 (stellenweise UTF-16), 16 Bit (ggf. 32 Bit), (fast immer) mit ebenfalls fester Länge.
Da aber bisher in Zusi nur sehr selten asiatische Buchfahrpläne oder Emoji etc. genutzt werden, käme es hiermit zu einer weitgehend nutzlosen Verdopplung der Größe von Textwerten bei der Datenübertragung, vom Little/Big Endian-Problem mal ganz abgesehen.
Die rückwärts-kompatible Umwandlung von UTF-16 in Windows-1252 für die Schnittstellen sollte hingegen kaum signifikante Zeitverluste verursachen, insbesondere durch den geringeren Zeitbedarf der anschließenden Speicheroperationen.
Als Alternative käme wohl UTF-8 in Betracht um sowohl Kompaktheit als auch Internationalität zu retten, aber es wären immer noch beidseitig (aufwändigere) Konvertierungen notwendig und die variable Länge der Abbildung von Zeichen außerhalb des ASCII-Zeichensatzes könnte ein Stolperstein werden (Länge in Bytes vs. Länge in Zeichen), wie auch generell die Verwechslung mit Windows-1252 (Mojibake).
Re: Vorankündigung Zusi 3.5
Schon das Yen-Zeichen ist nicht in 1252. Die richtigen Gegengleisklammern auch nicht. Auch Dinge wie ▽ müssen über Icons gemacht werden, was insbesondere dort sehr komplex wird, weil dort das ▽ eigentlich Teil des Fließtextes ist, also in Texten wie "Esig, ▽ Avsig" zwischen normalen Texten vorkommt. Wir haben zwar dort derzeit Workarounds drinnen. Aber vielleicht kommt für die Zukunft noch mal was ähnliches.
Das Endian-Problem würde ich hier nicht sehen, weil die zu lesenden Dateien UTF8 sind bzw. für XML ohnehin Standards existieren. Höchstens bei TCP könnte man die Frage stellen.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat