Kapitel 20 OR-Programmplattform

Open Rails Programmplattform


20.1 Architektur


Um besser zu verstehen, wie Open Rails funktioniert, zeigt das folgende Architekturdiagramm, wie der Softwarecode organisiert ist. Die Architektur der Open Rails-Software ermöglicht eine modulare Erweiterung und Entwicklung und bietet gleichzeitig standardisierte Methoden zur individuellen Anpassung des Simulationserlebnisses.


Hinweis: Bitte beachten Sie, dass dieses Diagramm viele Fähigkeiten und Funktionen enthält, die noch implementiert werden müssen.

20.2 Open Rails Game Engine


Die Open Rails-Software basiert auf der MonoGame-Plattform. MonoGame ist eine Open-Source-Implementierung des Microsoft XNA 4 Framework und bietet:


• Spielrahmen


• 2D- und 3D-Rendering


• Audioeffekt und -wiedergabe


• Tastatur-, Maus-, Touch- und Controller-Eingaben


• Erstellung von Inhalten und deren Verbesserung


• Für Spiele optimierte Mathematikbibliothek


20,3 Bildwiederholungsfrequenz (FPS)


Die FPS-Rate ist standardmäßig nicht an die Synchronisierungsrate des Monitors gekoppelt. Mit dieser Option kann die FPS-Rate jedoch auf den Wert der Bildwiederholfrequenz des Monitors eingestellt werden.


20.4 Spieluhr und interne Uhr


Wie andere Simulationssoftware verwendet auch die Open Rails-Software zwei interne Uhren; eine Spieluhr und eine interne Uhr. Die Spieluhr ist erforderlich, um die Bewegung der Züge und den Signalstatus zu synchronisieren und die richtige Spielumgebung darzustellen. Die interne Uhr wird verwendet, um den Softwareprozess für optimale Effizienz und korrekte Anzeige der Spielumgebung zu synchronisieren.


Das Team von Open Rails setzt sich dafür ein, dass die Spieluhr die Zeit in der Simulation richtig verwaltet, sodass ein Zug die richtige Distanz zur richtigen Zeit zurücklegt. Das Entwicklungsteam berücksichtigt diesen wichtigen Aspekt für eine genaue Simulation, indem es sicherstellt, dass die Aktivitäten auf den Computersystemen der Community-Mitglieder konsistent ablaufen.


20.5 Ressourcennutzung


Da die Open-Rails-Software für das MonoGame-Framework entwickelt wurde, nutzt sie nativ die Fähigkeit heutiger Grafikkarten, einen Großteil der Display-Rendering-Arbeitslast von der CPU des Computers zu entlasten.


20.6 Multithread-Codierung


Die Open Rails-Software ist von Grund auf so konzipiert, dass sie bis zu 4 CPUs unterstützt, entweder als virtuelle oder physische Einheiten. Anstelle eines einzelnen Threads, der alle Elemente der Simulation durchläuft und aktualisiert, verwendet die Software vier Threads für die Hauptfunktionen der Software.


• Thread 1 – Haupt-Renderschleife (RenderProcess)


• Thread 2 – Physik und Animation (UpdaterProcess)


• Thread 3 – Laden/Entladen von Formen und Texturen (LoaderProcess)


• Thread 4 – Ton


Es gibt andere Threads, die vom Multiplayer-Code verwendet werden, da jede geöffnete Kommunikation von einem Thread verarbeitet wird.


Der RenderProcess wird im Hauptspiel-Thread ausgeführt. Während der Initialisierung werden zwei untergeordnete Threads gestartet, von denen einer den UpdaterProcess und der andere den LoaderProcess ausführt. Es ist wichtig, dass der Updater-Prozess dem RenderProcess einen Frame voraus ist und alle Aktualisierungen von Kamera, Himmel, Gelände, Zügen usw. vorbereitet, die erforderlich sind, bevor die Szene ordnungsgemäß gerendert werden kann. Wenn nicht genügend Rechenressourcen für den UpdaterProcess vorhanden sind, um den nächsten Frame für den RenderProcess vorzubereiten, reduziert die Software die Framerate, bis sie aufholen kann.


Erste Tests deuten darauf hin, dass das Stottern erheblich reduziert wird, da der Prozess (LoaderProcess), der mit dem Laden von Formen und Texturen beim Überschreiten von Kachelgrenzen verbunden ist, nicht mit der Haupt-Rendering-Schleife (RenderProcess) um dieselben CPU-Zyklen konkurriert. Thread-Sicherheitsprobleme werden hauptsächlich durch Datenpartitionierung und nicht durch Sperren oder Semaphoren gelöst, um die Leistung zu maximieren.


Laufende Tests durch das Open Rails-Team und die Community werden feststellen, wo und wo die praktischen Grenzen der Software liegen. Da das Entwicklungsteam Feedback von der Community erhält, werden Verbesserungen und eine bessere Optimierung der Software zu einer besseren Gesamtleistung beitragen – was möglicherweise Modelle mit hohen Polygonen und dicht besiedelten Routen bei akzeptablen Bildraten ermöglicht.


20.7 Webserver


Das Spiel verwendet einen integrierten Webserver, um Standard- und benutzerdefinierte Webseiten an jeden Browser bereitzustellen. Dies kann auf demselben PC wie Open Rails oder einem anderen PC oder einem anderen Gerät ausgeführt werden, das mit Ihrem lokalen Netzwerk verbunden ist.


Der einfachste Weg, auf diese Beispiele zuzugreifen, besteht darin, das Spiel zu starten und dann einen Browser auf demselben PC zu starten. Geben Sie dann „localhost:2150“ in die Adressleiste Ihres Browsers ein. (2150 ist die Standard-Portnummer, die unter Menü > Optionen > Allgemein eingestellt ist)


20.7.1 Beispiel-Webseiten


In der Open Rails-Installation sind eine Reihe von Webseiten als Beispiele dafür enthalten, was mit den APIs möglich ist.


Einige dieser Beispielseiten wiederholen Daten aus den In-Game-Panels, um eine praktischere Anzeige zu ermöglichen. Die Beispielseiten befinden sich im Unterordner Content\Web des OR-Programmordners und der Webserver ist standardmäßig Content\Web\index.html.


Wenn Sie sich dafür entscheiden, Ihre eigenen Seiten zu entwickeln, denken Sie bitte darüber nach, diese mit der Open Rails-Community zu teilen.


• Die HUD-Webseite wiederholt die F5-Einblendung.

• Die Streckenmonitor-Seite wiederholt das F4-Fenster und ist auch mit dunklem Hintergrund für die Verwendung bei Nacht verfügbar.


• Die Seite „Zugfahren“ bietet ein Fenster, das in der offiziellen Version von Open Rails noch nicht verfügbar ist.


• Eine andere Seite bietet beides und die Fenster können für die beste Anordnung verschoben werden.

• Die Seite „Zeit“ zeigt die Simulationszeit als Digitaluhr und bietet Links zu drei Versionen einer Analoguhr.

• Die Kartenseite zeigt die Position und Richtung des Zuges in der realen Welt auf der OpenRailwayMap https://www.openrailwaymap.org. Es stehen verschiedene OpenRailwayMap-Layer zur Verfügung. Die Nutzbarkeit hängt von der Strecke ab, die Position des Zuges ist nicht immer 100 % korrekt.

20.7.2 Anwendungsprogrammierschnittstellen (APIs)


Der Webserver verfügt über eine einfache API, um Daten vom Simulator abzurufen. Antworten sind ODER-Datenstrukturen, die im JSON-Format serialisiert sind.


Sie können die JSON-Daten einfach durch Durchsuchen anzeigen. Beispiel: Navigieren Sie für APISample zu http://localhost:2150/API/APISAMPLE

Hinweis: Beim API-Teil dieser Adresse wird die Groß-/Kleinschreibung beachtet.


Hinweis: Um eine Überlastung des Simulators zu vermeiden, beschränken Sie API-Aufrufe bitte auf ein bis zwei Mal pro Sekunde.

Methode API call Beschreibung Response type
GET /API/HUD/<n> Ruft die auf dem <F5> HUD gerenderten Informationen ab, Zeile für Zeile, Seite für Seite, wobei <n> die HUD-Seitennummer 0 bis 7 ist. Orts.Viewer3D.WebServices .WebServer.ORTSApiController .HudApiArray
GET /API/ TRAINMONITOR or /API/TRAININFO Ruft auf dem Gleismonitor angezeigte Informationen ab, z. B. Geschwindigkeit, Beschleunigung, Steigung und bevorstehende Gefahren. Orts.Simulation.Physics .Train.TrainInfo
GET /API/TIME Ruft nur die Simulationszeit in Sekunden seit Mitternacht ab. Orts.Viewer3D.WebServices .WebServer.ORTSApiController .ApiTime
GET /API/MAP Ruft die Position und Richtung des Zuges ab. Neben verschiedenen Streckendaten von Open Rails. Orts.Viewer3D.WebServices .WebServer.ORTSApiController .ApiMap
GET /API/ CABCONTROLS Ruft ein Array der Cab-Steuerelemente für den Spieler localhost TypeName, MinValue, MaxValue, RangeFraction ab. Orts.Viewer3D.WebServices .WebServer.ORTSApiController .ApiCabControls
GET /API/APISAMPLE Ein Testobjekt, das die JSON-Serialisierung verschiedener Datentypen demonstriert. Orts.Viewer3D.WebServices .WebServer.ORTSApiController .ApiSampleData
Share by: