Monitorauflösungen

[stuvar]

Ich hab mir mal die Arbeit gemacht und die Auflösungen aus Steam ausgewertet. Dabei kam raus:

10,15 % der Monitore haben ein Seitenverhältnis kleines 14 zu 10 (das normale 4 zu 3 fällt darunter)*
89,54 % der Monitore haben ein Seitenverhältnis breiter als 15,9 zu 10 (16 zu 10 und 16 zu 9 fallen da mit drunter)*
Der marginale Rest ist irgendwas dazwischen.

* Die krummen Werte wurden gewählt damit ähnliche Auflösungen, die sich nur marginal vom 16/10 oder 4/3 unterscheiden auch mit erfasst werden.

Aufgrund der Diskusion 16/10 vs. 16/9 hab ich die nochmal auseinander gedröselt:
16 zu 10 kommt auf 15,88%
16 zu 9 hat 43,62%

Ultrabreite Monitore (Seitenverhältnis > 2 zu 1) fallen mit 0,18% praktisch nicht ins Gewicht. Den Aussagen, dass momentan 16/9 (bei Steam) vorherschend ist kann also zugestimmt werden. Zusammen mit 16 zu 10 haben sie auch die absolute Mehrheit.

Hochauflösende Monitore sind derzeit praktisch nicht vertreten (nur rund 0,1% haben eine Auflösung die an 4k rankommt). Die Technik ist für die Monitore aber noch in den Kinderschuhen. Meine Meinung zu dem Thema ist aber: Auf meinem Handy hab ich mittlerweile ne Auflösung von mehr als 300 ppi. Man erkennt dort sofort ob man ein hochauflösendes Bild vor sich hat oder ob es nur hochskaliert wurde. Mit den 4k-Filmen wird sich die Auflösung bald auch beim Monitorbereich durchsetzen so wie es HD momentan gemacht hat. Es wäre schön, wenn man schon vorher entsprechende Führerstandsfotos hätte damit man später 4k auch implementieren kann ohne neue Quellfotos erzeugen zu müssen.

Gerd

P.S: Für die alten Hasen: Die aus seeligen VGA-Zeiten bekannte Auflösung von 320x200 Pixeln war damals, (quadratische Pixel vorausgesetzt) umgerechnet auch nur 16 zu 10.

[drehorgelmann]

Hm, der Hausmeister geht zwar wieder um, aber was soll's...

Die Probleme in Richtung "Doku gegen Implementierung prüfen" erledigen sich von selbst, wenn man "contract first" implementiert und dazu sinnvolle Unit-Tests hat.

Links zum Thema:

Design by Contract: http://en.wikipedia.org/wiki/Design_by_contract" target="_blank

Unit Tests: http://en.wikipedia.org/wiki/Unit_testing" target="_blank

Die Kombination ist besonders bei zur Veröffentlichung vorgesehenen Schnittstellen sehr sinnvoll, ich würde sogar sagen, in der heutigen Zeit zwingend.

drehorgelmann

[drehorgelmann]

Hey Gerd,

besten Dank für die Auswertung.

Der wichtigste Punkt scheint mir dieser zu sein:

Es wäre schön, wenn man schon vorher entsprechende Führerstandsfotos hätte damit man später 4k auch implementieren kann ohne neue Quellfotos erzeugen zu müssen.

Wenigstens einer hier sieht das ähnlich...

drehorgelmann

[Carsten Hölscher]

Hm, der Hausmeister geht zwar wieder um, aber was soll's...

Wenn es gleich im ersten Anlauf klappt, einen lesbaren Beitrag zu schreiben, dann wäre das nicht nötig

Die Probleme in Richtung "Doku gegen Implementierung prüfen" erledigen sich von selbst, wenn man "contract first" implementiert und dazu sinnvolle Unit-Tests hat.

Hier entsteht tatsächlich erst Doku, dann die Ausführung, aber dazwischen steht im Moment ein Transfer der Doku von Openoffice nach Tex und der ist erstmal zu prüfen.

Carsten

[drehorgelmann]

Wenn es gleich im ersten Anlauf klappt, einen lesbaren Beitrag zu schreiben, dann wäre das nicht nötig

Hat doch im ersten Anlauf geklappt. Du hast den Beitrag zu 100% richtig verstanden und deshalb gelöscht.

Hier entsteht tatsächlich erst Doku, dann die Ausführung, aber dazwischen steht im Moment ein Transfer der Doku von Openoffice nach Tex und der ist erstmal zu prüfen.

Mit Verlaub, das glaub ich nicht (mehr). OO hat einen sehr guten PDF-Export, den könnte man problemlos rumschicken. Beim Transfer nach TeX wird ja nicht gleichzeitig der Inhalt angepaßt, und ob das PDF am Ende aus OO oder TeX generiert wurde, interessiert den Leser nicht die Bohne.

Wenn die Entwicklung schwierig wird und man vor einem Wollknäuel von Aufrufen steht, dann würde ich eher die Architektur überdenken, ggf. Refactoring machen und nicht ausgerechnet auch noch das Doku-Verfahren grundsätzlich ändern.

drehorgelmann

[Carsten Hölscher]

Hier zum weiteren nachlesen
http://forum.zusi.de/viewtopic.php?f=40&t=11696

Carsten

[drehorgelmann]

Hier zum weiteren nachlesen
http://forum.zusi.de/viewtopic.php?f=40&t=11696

Ahso, bei dir sind Link-Posts OK. Ist schon cool, daß man mit sich selbst immer etwas großzügiger sein kann als mit anderen

Aber Spaß beiseite: Der Thread ist im November 2013 gestartet, dein letzter Post dort ist vom 09.01.2014. Wie ist denn so der Stand, nach inzwischen 8 Monaten?

drehorgelmann

[drehorgelmann]

Wie ist denn so der Stand, nach inzwischen 8 Monaten?

... crickets.

q.e.d.

[F. Schn.]

Inhaltlich dürfte es jetzt stabil sein, ich müßte aber erst die Doku gegenchecken, bevor da jemand was macht.

Hallo Carsten,

dürfte ich mal vorsichtig fragen, was daraus geworden ist?

Gruß

F. Schn.

[Carsten Hölscher]

Ne, Doku wird der allerletzte Schritt in der Fertigstellung.
Carsten

[Mr. X]

Jetzt scheinst Du dich aber in Widersprüche zu verwickeln, da die OO->TeX-Konvertierung ja angeblich in letzter Zeit (in Zusi-Maßstäben) abzulaufen schien. Dokumentation sei ja inhaltlich auch vorhanden, das Interface vermutlich stabil (beides Deine Aussagen aus diesem Thread). Also wären nur drei Zustände denkbar:
- Fertig
- Konvertierung läuft noch immer
- Der Inhalt wurde nochmal über den Haufen geschmissen.

[drehorgelmann]

Jetzt scheinst Du dich aber in Widersprüche zu verwickeln

Hehe, hatte ich auch geschrieben. Bin ja schon gespannt, wie lange es dauert, bis du auch weg-gehausmeistert bist

drehorgelmann

[F. Schn.]

Hallo Carsten,

lohnt es sich dann noch, den Zusi-2-Protokollmüll aufzubohren, um damit auch Eingabevorgänge steuern zu müssen?

Ich rechne ja nicht damit, dass du Zusi 3 in den nächsten Monaten herausbekommst, außerdem hätte ich das Z3-Protokoll gerne noch mal öffentlich durchgesprochen, damit es als universelles I/O-Protokoll für Loksim & co verfügbar bleibt.

Mir geht es wie gesagt nur um das Protokoll, nicht um die ganze Zusi-3-Doku.

Gruß

F. Schn.

[St. Kunze]

Hehe, hatte ich auch geschrieben. Bin ja schon gespannt, wie lange es dauert, bis du auch weg-gehausmeistert bist
drehorgelmann

Ich verstehe es nicht, warum ihr dem drehorgelmann-Troll noch immer eine Plattform bietet. Sein einziger Daseinszweck ist Herumpöbeln und anderen Leuten die Doofheit bescheinigen. Warum tut ihr euch das an?

[Carsten Hölscher]

Die Konvertierung in tex steht noch an, dabei passiert gleichzeitig die inhaltliche finale Prüfung.
Carsten

[F. Schn.]

Das heißt, ich kann die Fernsteuerung von Zusi 2 nicht mit dem Zusi-3-Protokoll ausstatten?
Zumindest nicht vor der Release von Zusi 3 und das kann ja wie immer noch Jahre dauern...

[Carsten Hölscher]

Welche Zusi2-Fernsteuerung?
Carsten

[F. Schn.]

Mein Ursprünglicher Beitrag zu diesem Thema war:

Gegen sinnvolle Diskussionen ist ja nichts einzuwenden.

Gut, dann starte ich mal eine (hoffentlich sinnvolle) Diskussion:

Seit Monaten liegt bei mir zuhause eine DLL, mit der man Eingaben an Zusi 2 über das Windows-Messages-System tätigen kann - unabähigig davon, ob Zusi 2 den Eingabefokus hat und so weiter. Sie läuft inzwischen recht stabil. Aber ich scheue mich, die DLL zu veröffentlichen, ohne sie vorher an den TCP-Server angebunden zu haben. Sonnst werden nämlich einige Programme nur auf dem selben Rechner laufen, wie Zusi 2, und das halte ich für nicht gut.

Ich hatte von Anfang an eine Protokollerweiterung des Zusi-2-Protokolls in Planung. Aber inzwischen sehe ich diese kritisch: Jeder, der diese Fernsteuerungsfunktionen in seinem Programm nutzen möchte müsste diese Funktionen in seinen TCP-Client einbauen. Das sehe ich inzwischen als sehr viel Aufwand an, wenn das Protokoll ohnehin in Bälde durch ein Neues abgelöst werden sollte.

Vor einigen Jahren hast du gesagt, das Zusi-3-Protokoll "ist noch nicht so weit". Ich weiß nicht, ob sich das inzwischen geändert hat, aber langsam tendiere ich dazu, lieber das Zusi-3-Protokoll zu nutzen und ggf. zu erweitern, als eine Zusi-2-Protokollerweiterung vorzunehmen. Vielleicht ist es sogar positiv, das Z-3-Protokoll vor der Zusi-3-Release (wobei ja keiner weiß, wann die seien wird) mal öffentlich zu diskutieren?

Gruß

F. Schn.

Daraufhin hast du geantwortet:

Inhaltlich dürfte es jetzt stabil sein, ich müßte aber erst die Doku gegenchecken, bevor da jemand was macht.

Carsten

Und dazu habe ich jetzt noch einmal die obige Nachfage gemacht.

Gruß

F. Schn.

[Carsten Hölscher]

So ganz hab ich's nicht kapiert, aber ich würde mich deswegen jetzt ungerne von wichtigeren Aufgaben abhalten lassen.
Carsten

[Mr. X]

Es geht wohl einfach darum, die Spezifikation des Zusi-3-Protokolls offen zu legen. Was bereits im Vorfeld der Zusi-3-Veröffentlichung sinnvoll wäre, damit a) potentielle Probleme frühzeitig erkannt werden können und b) die Leute schonmal beschäftigt sind anfangen können, ihre Zusatzprogramme zu schreiben.