Der nächste Führerstandseditor und Frage
- Carsten Hölscher
- Administrator
- Beiträge: 33517
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Der nächste Führerstandseditor und Frage
mal eine kleine Vorschau auf den Zusi 3-Führerstandseditor.
Wie schon einmal irgendwo erläutert, ändert sich die Aufgabenverteilung zwischen bisherigem Fahrzeug- und Führerstandseditor etwas. Die techn. Einrichtungen, die mit der Führerstandsbedienung und Optik zu tun haben, wandern in den Führerstand.
Die Konvertierung ist nur ein Mausklick, der Zusi2-Fahrzeugeditor bekommt eine Funktion "Fahrzeug-Export" (hier jetzt kein Thema) und eine Funktion "Führerstandsexport". Diese lädt still im Hintergrund den 2.4-fst gemäß Lokdaten der lok-Datei und backt aus diesen Infos die neue Datei zusammen, wobei die Namen der Melder und Zeigerinstrumente gleich etwas freundlicher umgestaltet werden.
Das ganze im Zusi 3-Editor geöffnet sieht dann z.B. so aus (Fehlen bei der konkreten Lok noch ein paar Dinge):
Man hat also eine Seite mit den techn. Baugruppen, die werden hier direkt mit den für sie zuständigen Meldern vernüpft (hat der Exporter gleich alles richtig eingestellt - also das FbV wird in der Grafik durch den Melder "Schalter Führerbremsventil" repräsentiert - s. auch nächstes Bild).
Auf der 2. Seite findet man die Grafik, also den Nachfolger des bisherigen fst-Eddis:
(Originalgröße, 200 kB)
Im wesentlichen macht man hier das gleiche wie bisher auch. Aber das ganze läuft direkt unter DirectX, damit sieht man den Führerstand mit allen Effekten so wie später im Simulator. Man kann also die Tag-/Nacht-Schaltung und die Beleuchtung schon hier testen. Außerdem schalten die Elemente beim Testen völlig flackerfrei (die rote Markierung ist dann ausgeblendet).
Weiterhin läßt sich wie in Bildbearbeitungsprogrammen beliebig *) zoomen und scrollen (ohne daß es zu skalierten Ergebnissen führt wie bisher).
Damit ist der programmiermäßig eher undankbare Vollbildmodus nicht mehr nötig. Die Fensteraufteilung habe ich aber so eingerichtet, daß man bei einem 1280x1024-Bildschirm einen 1024x768-Führerstand komplett unskaliert darstellen kann (wie hier auf dem Bild).
Nun meine Frage an die Führerstandsbastler: Man könnte noch einiges an Speicher sparen, wenn man nicht für jede Schalterstellung ein eigenes Bitmap hätte, sondern möglichst viele der kleinen Bildchen platzsparend auf eine 2^x-Textur packen würde. Bei den einzelnen Melderbildchen ist eine Angabe über Texturkoordinaten schon seit 2.4 vorgesehen, die also dem Programm sagen würde, wo genau auf der großen Textur gerade das Bild zu finden ist.
Soweit also also Zusi-technisch alles kein Problem. Aber 1.) wie stellt man die große Textur zusammen? Vermutlich mit Photoshop kein großes Problem (?) und 2.) wie trifft man dann exakt "den Punkt" (man müßte quasi ein Referenzpixel o.ä. setzen, damit es beim Definieren des Ausschnitts (einer Schalterstellung) aus der großen Textur keinen ungewollten Versatz gibt).
Carsten
*) scheint da bei Extremversuchen wohl DirectX-bedingt zu Fehlern zu kommen
Wie schon einmal irgendwo erläutert, ändert sich die Aufgabenverteilung zwischen bisherigem Fahrzeug- und Führerstandseditor etwas. Die techn. Einrichtungen, die mit der Führerstandsbedienung und Optik zu tun haben, wandern in den Führerstand.
Die Konvertierung ist nur ein Mausklick, der Zusi2-Fahrzeugeditor bekommt eine Funktion "Fahrzeug-Export" (hier jetzt kein Thema) und eine Funktion "Führerstandsexport". Diese lädt still im Hintergrund den 2.4-fst gemäß Lokdaten der lok-Datei und backt aus diesen Infos die neue Datei zusammen, wobei die Namen der Melder und Zeigerinstrumente gleich etwas freundlicher umgestaltet werden.
Das ganze im Zusi 3-Editor geöffnet sieht dann z.B. so aus (Fehlen bei der konkreten Lok noch ein paar Dinge):
Man hat also eine Seite mit den techn. Baugruppen, die werden hier direkt mit den für sie zuständigen Meldern vernüpft (hat der Exporter gleich alles richtig eingestellt - also das FbV wird in der Grafik durch den Melder "Schalter Führerbremsventil" repräsentiert - s. auch nächstes Bild).
Auf der 2. Seite findet man die Grafik, also den Nachfolger des bisherigen fst-Eddis:
(Originalgröße, 200 kB)
Im wesentlichen macht man hier das gleiche wie bisher auch. Aber das ganze läuft direkt unter DirectX, damit sieht man den Führerstand mit allen Effekten so wie später im Simulator. Man kann also die Tag-/Nacht-Schaltung und die Beleuchtung schon hier testen. Außerdem schalten die Elemente beim Testen völlig flackerfrei (die rote Markierung ist dann ausgeblendet).
Weiterhin läßt sich wie in Bildbearbeitungsprogrammen beliebig *) zoomen und scrollen (ohne daß es zu skalierten Ergebnissen führt wie bisher).
Damit ist der programmiermäßig eher undankbare Vollbildmodus nicht mehr nötig. Die Fensteraufteilung habe ich aber so eingerichtet, daß man bei einem 1280x1024-Bildschirm einen 1024x768-Führerstand komplett unskaliert darstellen kann (wie hier auf dem Bild).
Nun meine Frage an die Führerstandsbastler: Man könnte noch einiges an Speicher sparen, wenn man nicht für jede Schalterstellung ein eigenes Bitmap hätte, sondern möglichst viele der kleinen Bildchen platzsparend auf eine 2^x-Textur packen würde. Bei den einzelnen Melderbildchen ist eine Angabe über Texturkoordinaten schon seit 2.4 vorgesehen, die also dem Programm sagen würde, wo genau auf der großen Textur gerade das Bild zu finden ist.
Soweit also also Zusi-technisch alles kein Problem. Aber 1.) wie stellt man die große Textur zusammen? Vermutlich mit Photoshop kein großes Problem (?) und 2.) wie trifft man dann exakt "den Punkt" (man müßte quasi ein Referenzpixel o.ä. setzen, damit es beim Definieren des Ausschnitts (einer Schalterstellung) aus der großen Textur keinen ungewollten Versatz gibt).
Carsten
*) scheint da bei Extremversuchen wohl DirectX-bedingt zu Fehlern zu kommen
-
- Beiträge: 649
- Registriert: 14.05.2002 18:13:13
- Wohnort: Mannheim
- Kontaktdaten:
- Carsten Hölscher
- Administrator
- Beiträge: 33517
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
-
- Beiträge: 649
- Registriert: 14.05.2002 18:13:13
- Wohnort: Mannheim
- Kontaktdaten:
- Carsten Hölscher
- Administrator
- Beiträge: 33517
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
solange es auf 2D-Texturbasis läuft ist es ega, wie man es im Detail organisiert. Ich werde das Prinzip nicht ändern, also es gelten die Fragen weiterhin.
Carsten
Carsten
Zuletzt geändert von Carsten Hölscher am 09.09.2005 21:46:10, insgesamt 1-mal geändert.
-
- Beiträge: 2422
- Registriert: 23.04.2002 17:27:44
- Aktuelle Projekte: Was in der Ausbildung lernen
- Wohnort: Nürnberg
- Kontaktdaten:
Geht ja schnell hier mit den Antworten, wollte grad was schreiben, da war die jpeg-Frage schon beantwortet.
Es gibt da so ein Programm von Daniel Schuhmann und mir, den "Zusi-Bitmapschneider". Dieser schneidet Bilddateien passgenau zu, so dass sie direkt für Führerstände einbaubereit sind.
Man könnte das Programm um eine Funktion erweitern, das die Bitmaps nach Wunsch auch in der gewünschten Art anordnet. Ein Betriebsversuch dazu läuft bereits
Wie ist es denn jetzt mit der Transparenzfarbe, bleibt das so wie momentan oder wird das einfach auf Schwarz festgelegt?
Zu deinem 2. Punkt in der ersten Nachricht, letzter Absatz: Wenn man das ganze per Programm zusammenstellen lässt, wäre es ja auch kein großes Problem, das alles direkt so benutzerfreundlich auszugeben für den Einbau.
Wünsche, Vorschläge, Probleme?
Es gibt da so ein Programm von Daniel Schuhmann und mir, den "Zusi-Bitmapschneider". Dieser schneidet Bilddateien passgenau zu, so dass sie direkt für Führerstände einbaubereit sind.
Man könnte das Programm um eine Funktion erweitern, das die Bitmaps nach Wunsch auch in der gewünschten Art anordnet. Ein Betriebsversuch dazu läuft bereits
Wie ist es denn jetzt mit der Transparenzfarbe, bleibt das so wie momentan oder wird das einfach auf Schwarz festgelegt?
Zu deinem 2. Punkt in der ersten Nachricht, letzter Absatz: Wenn man das ganze per Programm zusammenstellen lässt, wäre es ja auch kein großes Problem, das alles direkt so benutzerfreundlich auszugeben für den Einbau.
Wünsche, Vorschläge, Probleme?
Ich mag Besprechungen, da muss man nichts arbeiten.
-
- Beiträge: 649
- Registriert: 14.05.2002 18:13:13
- Wohnort: Mannheim
- Kontaktdaten:
Is das bei BVE nich auch so mit mehreren Bildern in einer Datei?
Aber ob das viel spart? Ob ich nun 10 einzelne Dateien hab oder die 10 als eine zusammenpappe...
Bsp:
10 x 20kb = 200kb
10 in 1 = 1x20kb + 180kb(die 9 anderen)
Und dann noch die kleinen Teilerstriche zwischen den Bildern.
Macht doch keinen Unterscheid...
Es wird allerdings übersichtlicher.
Falls es anders ist: Immer her mit der Belehrung
Aber ob das viel spart? Ob ich nun 10 einzelne Dateien hab oder die 10 als eine zusammenpappe...
Bsp:
10 x 20kb = 200kb
10 in 1 = 1x20kb + 180kb(die 9 anderen)
Und dann noch die kleinen Teilerstriche zwischen den Bildern.
Macht doch keinen Unterscheid...
Es wird allerdings übersichtlicher.
Falls es anders ist: Immer her mit der Belehrung
E-Mail: ThomasU@hotmail.de" (gleichzeitig MSN, so er denn funktioniert) oder mansg240h@web.de"
- Peter Zimmermann
- Beiträge: 9739
- Registriert: 07.11.2001 21:47:43
- Wohnort: RSI
-
- Beiträge: 649
- Registriert: 14.05.2002 18:13:13
- Wohnort: Mannheim
- Kontaktdaten:
Den lassen wir außen vor. Da bewegt sich nich genugPeter Zimmermann hat geschrieben:Fehlt nur noch Loksim.
E-Mail: ThomasU@hotmail.de" (gleichzeitig MSN, so er denn funktioniert) oder mansg240h@web.de"
-
- Beiträge: 2422
- Registriert: 23.04.2002 17:27:44
- Aktuelle Projekte: Was in der Ausbildung lernen
- Wohnort: Nürnberg
- Kontaktdaten:
@Thomas: Der Unterschied ist der Speicherverbrauch während des Einsatzes z. B. im Simulator.
Das ganze folgt dem Grundsatz, dass (rein technisch gesehen) mit Bildern gearbeitet wird, die quadratisch sind und immer ein Vielfaches von 2^x darstellen. Zum Beispiel 16x16 Pixel, 32x32, 64x64, usw...
Wenn man jetzt eine Textur hat, die meinetwegen 35x15 Pixel groß ist, läuft das im Endeffekt daraus hinauf, dass sie den Speicher einer 64x64-Textur belegen würde.
Diesen Effekt kann man verringern, indem man alles in eine große Datei speichert, dadurch wird der sowieso belegte Speicher besser ausgenutzt. Außerdem fallen bei Schaltern mit meinetwegen 10 Stellungen eben nicht so viele eigentlich kleine Bitmaps an, die übermäßig viel Speicher belegen, sondern der ganze Verlust bewegt sich in einem viel kleineren Bereich.
Ich hoffe, es war einigermaßen verständlich erklärt...?
Das ganze folgt dem Grundsatz, dass (rein technisch gesehen) mit Bildern gearbeitet wird, die quadratisch sind und immer ein Vielfaches von 2^x darstellen. Zum Beispiel 16x16 Pixel, 32x32, 64x64, usw...
Wenn man jetzt eine Textur hat, die meinetwegen 35x15 Pixel groß ist, läuft das im Endeffekt daraus hinauf, dass sie den Speicher einer 64x64-Textur belegen würde.
Diesen Effekt kann man verringern, indem man alles in eine große Datei speichert, dadurch wird der sowieso belegte Speicher besser ausgenutzt. Außerdem fallen bei Schaltern mit meinetwegen 10 Stellungen eben nicht so viele eigentlich kleine Bitmaps an, die übermäßig viel Speicher belegen, sondern der ganze Verlust bewegt sich in einem viel kleineren Bereich.
Ich hoffe, es war einigermaßen verständlich erklärt...?
Ich mag Besprechungen, da muss man nichts arbeiten.
- Daniel Rüscher aka Merlin
- Beiträge: 2294
- Registriert: 23.01.2003 02:25:50
- Aktuelle Projekte: Aktuell keine
- Wohnort: Traunreut
- Kontaktdaten:
Hallo Carsten,
Wie wäre es denn mit einer Weiteren Funktion für den Lokeditor?
Beim Import werden die Bitmaps einfach in eine Datei eingefürt (Das Tool kann ja beim öffnen ein Grid drüberlegen um evtl. auch umsortieren zu können)
Beim Ausschneiden mit dem eingebauten Bitmapeditor (wenn geplant) wird auch wieder in eine Datei gepakt und Grid drübergelegt.
Beim manuellen Ausschneiden mit Paintshop o.ä. erzeugt man sich erst ne Leere Datei mit Grid (Größe angebbar) und zieht sich dann die einzelnen Datein da rein. Beim Spechern wird dann alles zu einer Textur zamgewuzelt.
Anhand des Grids kann man ja dann die genaue "Erstpixel" Psoition feststellen.
Wenn die Idee für dich halbwegs annehmbar klingt, dann kann ich ja moren mal nen GUI Entwurf samt zugehöriger Beschreibung erstellen, wo das etwas ausführlicher Erklärt wird.
Gurß Daniel
Wie wäre es denn mit einer Weiteren Funktion für den Lokeditor?
Beim Import werden die Bitmaps einfach in eine Datei eingefürt (Das Tool kann ja beim öffnen ein Grid drüberlegen um evtl. auch umsortieren zu können)
Beim Ausschneiden mit dem eingebauten Bitmapeditor (wenn geplant) wird auch wieder in eine Datei gepakt und Grid drübergelegt.
Beim manuellen Ausschneiden mit Paintshop o.ä. erzeugt man sich erst ne Leere Datei mit Grid (Größe angebbar) und zieht sich dann die einzelnen Datein da rein. Beim Spechern wird dann alles zu einer Textur zamgewuzelt.
Anhand des Grids kann man ja dann die genaue "Erstpixel" Psoition feststellen.
Wenn die Idee für dich halbwegs annehmbar klingt, dann kann ich ja moren mal nen GUI Entwurf samt zugehöriger Beschreibung erstellen, wo das etwas ausführlicher Erklärt wird.
Gurß Daniel
How to waste bits in a My SQL Database?
Like this.....
Like this.....
Jau, hab´s verstandenSebastianSperling hat geschrieben:Ich hoffe, es war einigermaßen verständlich erklärt...?
Lernt man sowas im Informatik-Unterricht auch?
E-Mail: ThomasU@hotmail.de" (gleichzeitig MSN, so er denn funktioniert) oder mansg240h@web.de"
-
- Beiträge: 2422
- Registriert: 23.04.2002 17:27:44
- Aktuelle Projekte: Was in der Ausbildung lernen
- Wohnort: Nürnberg
- Kontaktdaten:
- Carsten Hölscher
- Administrator
- Beiträge: 33517
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
die Bilderverteilung beim MSTS ist aber nicht gerade der Weisheit letzter Schluß. Vom programmiertechnischen Aspekt her habe ich jetzt ein völlig offenes System erstellt. Man könnte also sogar einzelne Bilder drehen usw. um den Platz optimal auszunutzen. Wäre eigentlich schade, das jetzt durch ein "stumpfsinniges" Anneinanderreihen der Bilder wieder zu verschenken. Daher hatte ich einen Automatismus wie von Daniel (R.) angedeutet wieder verworfen. Wenn sich sonst nur eine sehr komplizierte Lösung abzeichnet, könnte man natürlich doch drüber nachdenken...
Carsten
Carsten
- Daniel Schuhmann
- Beiträge: 1147
- Registriert: 21.04.2003 18:50:37
- Aktuelle Projekte: Nüscht
- Wohnort: Miesbach
- Kontaktdaten:
Servus!SebastianSperling hat geschrieben:Es gibt da so ein Programm von Daniel Schuhmann und mir, den "Zusi-Bitmapschneider". Dieser schneidet Bilddateien passgenau zu, so dass sie direkt für Führerstände einbaubereit sind.
Man könnte das Programm um eine Funktion erweitern, das die Bitmaps nach Wunsch auch in der gewünschten Art anordnet. Ein Betriebsversuch dazu läuft bereits
Hier ein paar Ergebnisse des "Betriebsversuchs": Der Schneider hat zuvor ein paar Führerbremsventil-Bildchen auf die kleinstmögliche Größe geschnitten:
Anklicken zum Vergrößern
Mit der neuen Funktion werden diese hernach automatisch angeordnet. Da es 13 Bilder sind, ist die nächstbeste Größe 4 * 4.
Anklicken zum Vergrößern
Carsten, paßt das so?
Signaturen können bis zu 50 Zeichen lang sein und
- Daniel Schuhmann
- Beiträge: 1147
- Registriert: 21.04.2003 18:50:37
- Aktuelle Projekte: Nüscht
- Wohnort: Miesbach
- Kontaktdaten:
Auch so etwas wäre umsetzbar. Der Schneider nimmt zur Zeit von sich aus die minimal mögliche Bildgröße für eine Gruppe von Dateien (im Beispiel oben eben für alle Bremsventilschalterchens). Der Schneider weiß aber natürlich auch die kleinstmögliche Größe für jedes einzelne Bild, diese dann passend hinzupuzzlen sollte nicht so das große Problem sein.Carsten Hölscher hat geschrieben:Man könnte also sogar einzelne Bilder drehen usw. um den Platz optimal auszunutzen. Wäre eigentlich schade, das jetzt durch ein "stumpfsinniges" Anneinanderreihen der Bilder wieder zu verschenken.
Daniel
Zuletzt geändert von Daniel Schuhmann am 10.09.2005 01:50:01, insgesamt 1-mal geändert.
Signaturen können bis zu 50 Zeichen lang sein und
- Carsten Hölscher
- Administrator
- Beiträge: 33517
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
mmmh, also
1.) es darf auch "instrumentenübergreifend" sein (also eine Textur kann mehrere Schalter/Melder-Inhalte enthalten oder auch umgekehrt).
2.) Man könnte die Leeräume doppelt benutzen, um Platz zu sparen. Also für ein Instrument sollen zwar weiterhin alle Schalterstellungen dieselben Abmaße behalten, aber der Leerraum drüber und drunter könnte von beiden Bildnachbarn benutzt werden.
Ich hoffe, ich habe mich halbwegs verständlich ausgedrückt...
Carsten
1.) es darf auch "instrumentenübergreifend" sein (also eine Textur kann mehrere Schalter/Melder-Inhalte enthalten oder auch umgekehrt).
2.) Man könnte die Leeräume doppelt benutzen, um Platz zu sparen. Also für ein Instrument sollen zwar weiterhin alle Schalterstellungen dieselben Abmaße behalten, aber der Leerraum drüber und drunter könnte von beiden Bildnachbarn benutzt werden.
Ich hoffe, ich habe mich halbwegs verständlich ausgedrückt...
Carsten
- Daniel Schuhmann
- Beiträge: 1147
- Registriert: 21.04.2003 18:50:37
- Aktuelle Projekte: Nüscht
- Wohnort: Miesbach
- Kontaktdaten:
Noch schnell ein Nachtrag (heute überschneiden sich aber wirklich alle Beiträge): Der Bitmap-Schneider schaut ja, an welchen Stellen "Daten" sind, also weiß er auch, wo sich Leerräume befinden, in die man Schalter, Leuchtmelder usw einsetzen könnte. Rein logisch überlegt kommt mir aber die Möglichkeit "kleinstmögliche Einzelbilder" zu erstellen und die dann ggf zu drehen leichter vor. Beides in Kombination könnte natürlich noch mehr an Speicher sparen - die Frage wäre dann, wie lang das Programm rechnet, um das Bitmap zu generieren.
Daniel
Daniel
Signaturen können bis zu 50 Zeichen lang sein und