Posts by Hoogo

    "Serious Sam 2nd encounter".

    Als es "Serious Sam" letztens umsonst gab, hab ich für ein paar Cent auch noch den zweiten Teil hinzugenommen.


    Der erste Teil war hirnloses Ballern "seriös", wie Duke Nukem ohne Witz. Aber doch arg übertrieben "seriös" und damit doch witzig.

    Der zweite Teil versteckt zwischen dem normalen Ballern einiges an Blödeleien, die vollkommen aus der Story fallen.

    Kein Super-Spiel, aber für die paar Kröten doch eine spaßige Unterhaltung.


    "Goat Simulator" empfiehlt sich, wenn man mal wieder was völlig absurdes braucht.

    Oh, mit so einer heftigen Reaktion hätte ich jetzt nicht gerechnet. :)


    Sehen das andere Coder auch so? Ich werde davon aber nicht abrücken, genauso wenig wie von globalen Variablen in vb.net oder dem Ausschalten von Option Strict im Visual Studio. :whistling:

    Das große Problem wurde ja schön geschildert: 2 Programmteile, die das Gleiche machen SOLLEN, aber irgendwann im Laufe der Jahre geht die Pflege schief, und sie machen was unterschiedliches.

    Im konkreten Fall, so 1:1, wie Du ihn geschildert hast, hilft es eigentlich gar nicht: Während des Debuggings nutzt Du eine verlässliche Routine, aber die Release-Version wird dadurch nicht besser oder vertrauenswürdiger.


    Was ich vergleichbares an Flags in meinem Programmierer-Leben habe:

    Ein DEV-Flag (durch IDE erkennen oder Parameter).
    - Manchmal, um Quick and Dirty mit bestimmten Datensätzen statt echter Abfragen zu testen, Plausi-Prüfungen zu umgehen o.Ä.

    - manchmal, um damit Fehlerbehandlungen abzuschalten. Fehler-Popups sind einfach praktischer als Mails ans Ticket-System.


    Ein OPTIMIZE-Flag, wie es Stingray glaub ich meint. Für Code, dem man nicht recht vertraut, wie im Beispiel.

    - Im besten Fall schaltet es weitere, langsame Plausi-Prüfungen oder Log-Meldungen frei, im Beispiel einen Vergleich mit der Original-Formel.

    - In komplizierten Fällen bekommen Anwender auch mal 2 Menüpunkte (Alt / Neu, Test). Man erreicht nicht immer Einigung darüber, was richtig oder falsch ist. Und falls es falsch ist, bleibt dem Anwender noch eine Alternative.


    Ein ähnliches Flag für Datenaustausch mit Kunden.

    Manchmal wollen Schnittstellen zu bestimmten Zeitpunkten scharfgeschaltet werden, wenn man schon längst zur nächsten Baustelle weitergezogen ist. Dann schleppt man halt für eine Weile den alten Code mit.

    Davon würde ich Dir dringend abraten!!

    Du holst Dir so nur unnütz mehr Arbeit in dein Projekt und hast deutlich höheren Wartungsaufwand!!

    Auch ist dieses Vorgehen deutlich fehleranfälliger - man ändert so schnell mal was nur an einer Stelle um kurz etwas zu testen und wundert sich dann wieso es bei Release auf einmal fehlerhaft läuft.


    Von so einem Konstrukt bitte absehen...

    Also im konkreten Fall, zur Auswahl einer einfachen/verständlichen Version oder einer schnellen/unverständlichen Version, stimme ich gerne zu. Wobei es an der Stelle aber nahe liegend ist, beide Versionen zu berechnen und zu vergleichen, was dann schnell zu einem "Unit test" wachsen kann.


    Aber so ganz generell finde ich für IF DEBUG oder IF IDE doch sehr nützliche Anwendungen, auf die ich nicht verzichten wollte.

    "Panzermadels Tank dating simulator" hab ich lange nicht mehr gezockt, das könnte ich mir mal wieder antun.


    Ein junger Japanischer Soldat ist in eine Panzerschule abkommandiert und stellt dort fest, dass es eine Schule FÜR Panzer ist und alle Panzer dort WWII-Tanks in Gestalt von Manga-Mädchen sind, die man dann anbaggern kann.

    Selten absurd... Mit gewissen Geschichts-, Panzer- und Englisch-Kenntnissen kommen viele Wortspiele noch besser.Spielerisch ist es nur eine simple Multiple-Choice-Sache, aber der Spaß ist allemal 5,- wert, wenn es mal im Angebot ist.

    So gings/gehts mir bei Red Dead 2.

    OT:
    Ich hab das Spiel noch nicht life gesehen, aber über diverse Bugs and Glitches habe ich mich bei YT wochenlang beömmeln können.


    Die ersten Metro-Teile sind schön, um sich einfach nur umzusehen. Aber halt kein Openworld und zwischendurch zu hektisch, so dass man manche Stellen nicht wirklich genießen kann. Die Brücke im Regen ist wundervoll, aber das Gequatsche und die Gegner stören.

    Du meinst sicherlich was komplizierteres aber an sich ist das doch ganz normal: kein Licht = keine Farbe ("nachts sind alle Katzen grau"), wenig Licht = wenig Farbe, mehr Licht = mehr Farbe. In der Dämmerung kann kaum jemand Farben unterscheiden, bei Sonnenschein geht es besser. Aber wie gesagt, du wirst etwas anderes meinen ...

    Ja, ich denke, ich weiß, was er meint. Wenn doch die Iris sich so weit zusammenzieht, dass die gleiche Intensität an Licht einfällt wie in einer etwas dunkleren Umgebung, wo sie weiter aufgeht, wäre es ja logisch, wenn auch das Farbsehen identisch wäre. Ist es aber nicht. Das Spektrum verändert sich anscheinend, und, wie wir ohnehin wissen, der Streulichtanteil. Möglicherweise wird die Farbe generell intensiver, aber ab einer bestimmten Sättigung übersteuert die Wahrnehmung bzw. signalisiert früh Vollsättigung, während bei den r/g-Schwachen die Vollsättigung bei r/g nicht oder später erreicht wird. Viele mögliche Ansätze.

    Ich denke, es hat auch was mit dem Lichtspektrum zu tun.

    Ja, ius hat genau das Verstanden, was ich meinte.


    Klar ist mir:
    Wenn ich mich JETZT so umgucke, wo es kurz vor der Dunkelheit ist, da wundert es mich nicht, dass Sachen mit den knaatschigsten Farben nur noch blass gefärbt sind. Alle "Farbkanäle" sind nur noch knapp über Schwarz, das ist wie ein unterbelichtetes Foto.

    Bei perfektem Licht wäre die Chipstüte da hinten $ff0101, da ist ordentlich Unterschied in der Dynamik von Rot zu den anderen Kanälen, das wäre ordentlich satte Farbe.

    Aber jetzt ist da bestenfalls noch $080101 übrig, da ist so wenig Dynamik übrig, ich sehe kaum noch Farbe.

    => DAS meinte ich nicht.


    Das ist halt so ne komische alte Fotografen-Weisheit:

    Bei Sonne gibt es knallige Farben, bei weniger Licht wird es neutraler.

    Vom Gefühl her ist das so wahr...Obwohl man den Film immer gleich gut belichten kann, indem man die Belichtungszeit anpasst!

    Ist wie mit der Pupille, die ius genannt hat: Das Farbsehen MÜSSTE eigentlich gleich sein, aber irgendwie ist es das nicht.


    Ich hab es nie kontrolliert oder Experimente dazu gemacht.

    Vielleicht ist es ja auch nur Einbildung oder eine andere Form von optischer Täuschung, dass bei Sonnenschein die Farben satter sind.

    ...Alle Mischfarben sind Metamere zu realen Spektren, aber auf dem Monitor eindeutig durch die Tristimulus-Werte (RGB) definiert, also im Rahmen der wahrnehmbaren Differenzen unterscheidbar....


    ...Umgekehrt: 2 reale Spektren, die für einen Trichromaten metamer sind (also als gleiche Farbe wahrgenommen werden), können aber durchaus für einen Tetrachromaten unterschiedlich aussehen...

    Das sehe ich auch so, aber der Test basiert nicht auf Metamerie.

    Die prüfen, wie gut ähnliche Farben zu unterscheiden sind.


    Nach meinem Verständnis funktioniert das nur, weil die Empfindlichkeiten im Auge alles andere als scharf begrenzt sind.

    Schick ein bisschen mehr Grün über den Monitor, und alle Zäpfchen werden darauf reagieren - egal, ob Du nur grüne oder grüne und gelbe hast.

    Farben werden im Auge als Differenz (oder Verhältnis?) verschiedener Zäpfchen "berechnet". AFAIK sind da schon im Auge spezialisierte Zellen für da, es geht gar kein RGB (+Helligkeit) ins Hirn.

    Diese Verschaltung im Auge ist wohl fest auf 3 Werte in Richtung Hirn festgelegt, echte Tetrachromaten können Menschen damit nicht sein.

    Aber offenbar verbessert sich doch die Unterscheidbarkeit, wenn an manchen Stellen Grün + Gelb oder Rot + Gelb statt nur Grün + Rot verrechnen kann.

    EDIT:
    Stäbchen haben auch eine spektrale Empfindlichkeit.
    IM PRINZIP wären also eh 4 verschiedene Sensoren im Auge, was Tetrachrmatik erlauben müsste.

    Wenn da halt nicht diese Verschaltung im Auge wäre, die alles auf 3 "Vergleiche" zusammendampft.

    Und das ist nur mein Verständnis des Ganzen, man kann sicher noch tiefer ins Thema rein.

    Der Film legt u.a. nahe, dass wir eine Farbe erst "sehen" (im Gehirn unterscheidbar wahrnehmen), wenn wir sie benennen können. Ich kenne alte Texte, die den Himmel nicht als blau bezeichnen und die Heide als braun (statt violett).

    Altgriechische Tempel waren bunt. Hauptsächlich Blau, Rot, Weiß.

    Ishtar-Tor aus Babylon: Blau-Gold
    Tausend Jahre vorher haben die Minoer Blau benutzt

    Tutenchamuns Totenmaske: Blau-Gold.

    Sumer vor knapp 5000 Jahren: Blau und Rot

    Indigo in Indien und Peru ca. 6000 Jahre.

    Viel weiter kann die Historie nicht zurückgehen.

    Blau war als Farbe verfügbar, Azurit war damals wohl der Hit, Indigo auch in Griechenland bekannt.

    Zumindest den Teil "Blau war als Farbe schwer verfügbar" würde ich so nicht stehen lassen wollen.


    "Azur", "Türkis" und "Indigo" sind auch alte Wörter. Wenn mich jemand nach Azur oder Indigo fragen würde, ich hätte keine Ahnung, sind für mich einfach "Blau", so wie Fuchsia für mich einfach "Rot" ist.


    Was ich gerne akzeptiere:
    In den abstrakteren Ebenen der Wahrnehmung basiert viel auf Mustervergleich und Training.

    Wenn man Blau, Grün und Violett trainiert hat und dann Indigo sieht, dann wird man das auf abstrakterer Ebene genau so einsortieren, wie man eine der anderen Farben einsortiert. Imho braucht es dazu aber kein "benennen".

    Wenn direkt 2 Farbfelder aneinanderstoßen, dann wird man die leicht trennen können, egal, ob man mit dem namen Indigo was anfangen kann oder nicht.

    Wenn man aber hin- und herblicken und das Gedächtnis bemühen muss, dann wird man es schwer haben.


    Der Farbeindruck lässt sich z.B. im hellen Sonnenlicht oder bei extremem Halogenlicht herstellen, wenn das Auge die Helligkeit kompensiert, aber die Farbsättigung erhöht ist.

    Wo wir grad alle so schön beisammen sind:

    Ich hab für mich noch keine Erklärung gefunden, warum mehr Licht für sattere Farben sorgt.

    Die HSL-Sättigung ist das Verhältnis von stärkstem zum schwächsten Farbkanal.

    Doppelt so viel Licht ändert ja nichts am Verhältnis - und trotzdem wirkt es satter.

    Hat da jemand ne schöne Erklärung für?
    Sowas wie "bloß nicht linear die Photonen vergleichen, sondern für die Sättigung vorher ne Kurve anwenden" oder sowas.

    Da kommen mir grad Ideen...

    - Simulation solcher Fehlsichtigkeiten müsste auch mit Farbprofilen gehen, so dass eine Art Proof in allen Anwendungen und auch Desktops möglich sein müsste.

    - Und eigentlich müsste auch der umgekehrte Weg mit Einschränkungen möglich sein: Farbprofile, die den Farbraum derart verknautschen, dass die schlecht unterscheidbaren Farben woanders hingemappt werden.

    joshy Der Tretroller- Vergleich hinkt, wenn hier nur die Geschwindigkeit und Grösse der Massenspeicher bemängelt wird. Und das hat sich am C64 doch extrem verbessert?

    Also ist es nicht eher so, das der C64 damals ungeeignet war, jetzt aber wesentlich besser dasteht, wenn es ein modernes COBOL für ihn gäbe, was die neuen Möglichkeiten nutzt?

    "Das passt nicht zusammen" und "ist ganz anders" ist natürlich nicht sehr plastisch...


    Unsere Unisys hatte keine Bytes, sondern 36-Bit-Worte.

    Wo der 64er 65535 Adressen hat, hatte so ein früher Großrechner auch nicht unbedingt mehr. 64K Adressen war sagen wir mal Stand der 60er.

    Unterm Strich war der Speicher also doch recht schnell voll. Und das Ding musste nicht nur 1 Programm laufen lassen, sondern kam mit mehreren Programmen verschiedener User gleichzeitig zurecht, die aber nie komplett im Speicher waren.

    Und an die Dinger konntest Du dann dutzende Tapes anschließen, die je 1MB die Sekunde liefern konnten.


    Wenn ich das so auf C64 übertrage:

    - Die großen Steckmodule haben ein bisschen Ähnlichkeit, wenn sie Code nicht direkt ausführen, sondern einzelne Code-Module bei Bedarf rüberkopiert werden. Nur stammen die Code-Schnipsel von ganz verschiedenen Leuten und sind frei im Speicher zu verschieben.

    - Ein normaler Loader für die 1541 liest ja einen Sektor, bearbeitet ihn und übermittelt ihn dann an den 64er. Die allermeiste Zeit wartet der 64er auf die Floppy. Das geht GAR nicht!! Da müssen mindesten 5 Floppys dran, damit die CPU ordentlich ausgelastet wird - Von 5 verschiedenen Programmen verschiedener User. Und natürlich noch Extra-Hardware je Floppy am Anschluß, um zu puffern und die Bytes nicht per Code abholen zu müssen.

    - Programme wurden auch entladen, während der Operator grad nach den nötigen Tapes sucht. Irgendwer freut sich über den freien Speicher.

    - Es gibt kein Bildschirm-RAM, keine Tastatur, keinen direkten Kontakt mit dem User. Stattdessen aber schon hunderte oder tausende Terminals. Ich erinnere mich an ein Gerät mit Namen "Konzentrator", ein kleiner Großrechner von der Größe einiger Kühltruhen. Das Ding hat ankommende Daten der Terminals aufbereitet, damit der eigentliche Rechner das Zeug in einem Rutsch gleich wegarbeiten konnte.

    - Für die Terminals muss es so eine Art von Winz-html für Textmodus gegeben haben. An den Teil erinnere ich mich nicht mehr, aber ich wette, das wurde wie sequentielle Dateien programmiert.


    Dieses ganz andere Umfeld macht sich auch hier und da an der Sprache bemerkbar.

    Datensätze fester Länge waren hui, variable Länge war pfui. Ungefähr so wie "BIF-Basic" - Kann man machen, muss man aber nicht.


    Falls Du also mit dem 64er in einem Nachtlauf die täglichen Bewegungsdaten (Materialentnahmen, Bestellungen usw.) eines Anlagenbauers durchackern willst, Konten und Materialbestände updaten willst und auch noch die clevere Hardware drumrum hast, dann wird das bestimmt ne gelie Sache mit Cobol.

    Aber für heute übliche Programme? struuunz sagt, dass es dafür was gibt, aber ich kann mir nicht vorstellen, dass ich begeistert wäre.

    Die Datenverarbeitung war in den meisten Fällen ja halb-interaktiv. Die IBM-Terminals bekamen vom Host eine Eingabemaske, in die die Daten für die aktuelle Transaktion lokal eingetragen wurden. Das ging recht flott, da alles im Terminal passierte. Dann wurden diese lokalen Daten auf Knopfdruck wieder an den Host gesendet. Während der Eingabezeit konnte der Host sich um andere Transaktionen kümmern.

    Ich erinnere mich an die TIPS, "Transacrtions in progress / sec", die auf dem Hauptterminal der Unisys in den Monitor gebrannt wurden.

    An VT100-Emulatoren (für die jüngere DEC?) erinnere ich mich auch, und die Bildchen vom IBM-Emulator kommen mir auch ein bisschen vertraut vor.

    Aber dass ich dazu mal irgendwas programmiert hätte... Ne, nix, kein bisschen Erinnerung.

    Was hatten denn die Rechner aus den 50er, 60er, 70er Jahren, was dem C64 fehlt?

    Eine aufwändige, professionelle Infrastruktur. Massespeicher heißt 1970 große Bandlaufwerke und Trommel/Plattenspeicher.

    Du fragst ja auch nicht, warum man mit einem e-Tretroller keinen Motorrad-Grand-Prix mitfahren kann, obwohl der einen Motor und zwei Räder hat.

    Das wird leicht unterschätzt, wenn man die Dinger nicht irgendwann mal irgendwie kennengelernt hat.

    Ich musste mich auch erst wieder nachschlauen.
    IBM 727 von 1953 schaffte umgerechnet ~12 KByte in der Sekunde.

    In den 60ern waren dann schon MByte drin, und was wir Ende der 80er/Anfang der 90er am Großrechner gesehen haben war bestimmt mindestens auf dem Stand der 70er.
    Oder wie xkcd mal sagte: Man soll den Datendurchsatz eines LKWs voller Magnetbänder nicht unterschätzen.


    Großrechner und das Cobol dazu sind "anders" als heutige Programmierung.

    Ich erinnere mich nicht im geringsten an sowas wie "User-Interface" oder Bildschirmmasken, oder wie man das am Großrechner programmiert hätte.

    Ich erinnere mich vor allem an die Verarbeitung großer, serieller Text-Dateien.

    Das ist irgendwie so nix C64-typisches.

    ich erkenne es in den XML-Dateien wieder, die heute wohl zu C#-Programmen gehören.

    :gruebel

    Vielleicht erinnere ich mich auch schlecht oder hab nur einen beschränkten Ausschnitt von C# gesehen.


    Die JCL enthielt Einstellungen für das Programm, eine Art INI-Datei.

    Der Batch-Betrieb ohne eine UI brachte es aber halt mit, dass man an diesen Dateien ständig gearbeitet hat.

    Dateinamen für Input und Output steckten darin, Datenbank-Namen, Druckerqueues waren angegeben, aber auch so Dinge wie die Abteilung, die die Prozessorzeit bezahlen muss.


    JCL und Programm kamen immer zusammen, und es war völlig normal, ganz verschiedene JCL zu haben.


    Und in C# schieb ich ein Programm auf den Server, und ohne die zugehörige XML-Datei mit den Einstellungen des Frameworks, Datenbankpfaden usw. läuft da gar nix. Und mit verschiedenen XML-Dateien kann ein Programm z.B. in der Produktiv- oder in der Testumgebung laufen.

    Doch Achtung! auf den Mainframes der 70er war vieles anders ... Batchbetrieb ... mit einem JCL-Programm (Job Control Language) zur Verarbeitung los geschickt.

    Ich mochte das Konzept mit JCL, ich erkenne es in den XML-Dateien wieder, die heute wohl zu C#-Programmen gehören.