Posts by Hoogo

    Wir duschen bei uns alle nach der Arbeit und dort gibt es Leute die sind so bekloppt die lassen das Wasser laufen und hauen ab.

    Da bekomme ich echt zuviel.

    Solche Kameraden hab ich im Büro auch. Im Winter Fenster auf und Heizung an, im Sommer Fenster auf und Klima an. PC läuft incl. der Monitore 24/7...

    Leider regnet es nicht immer dort ab, wo es dringend nötig wäre sondern auch da, wo es zu Überschwemmungen führt.

    Ja, das kann echt ironisch sein, in der Sahara bei Regen zu ertrinken, aber das passiert. Das brauchen die echt nicht öfters.

    Ich frage mich, ob es nicht technisch möglich sein müsste, solche Regenfälle wenigstens teilweise zu stauen? Klingt irgendwie doof, in einer Wüste Staumauern zu bauen... Aber das ist eh schon Geo-Engineering.

    Wie wird sich das verändern, nun zum Ende der Eiszeit, wo wie aus der Erdgeschichte bekannt, sämtliche Eismassen abschmelzen werden ?

    "Unsere" letzt Eiszeit endete vor 8000 Jahren. Der Meeresspiegel ist dabei um 120 Meter gestiegen und hat damals Doggerland überschwemmt.

    Aber das hat Jahrtausende gedauert, und die paar Menschlein konnten woanders hinwandern, die waren eh noch nicht richtig sesshaft.


    Die letzten 8000 Jahre war der Meeresspiegel sehr konstant. Wie viel Meter Anstieg sind geboten, wenn alles Inlandeis abschmelzen sollte? 60 Meter oder so?

    Wenn man das so sieht, dann ist Geld auch nicht weg, nur weil man es ausgegeben hat und pleite ist. Das Geld hat hat dann nur jemand anderes - aber was nützt es einem dann noch?


    Zahlen von 2013: Hier schnell was gegoogelt.

    - 3,5 Milliarden cbm Grundwasser wurden entnommen. Füllen die sich auch schnell genug wieder aus Regen und Flüssen nach, dass man weiter Wasser aus den gewohnten Brunnen nehmen kann?

    - Aus Gülle gelangt Nitrat, aus Phosphat-Düngung gelangt Uran ins Grundwasser. Wie aufwändig ist die Aufbereitung, geht das überhaupt, oder muss man dann schlimmstenfalls Grundwasser als Schmutzwasser betrachten? Grad das mit dem Uran hat heute schon originelle Konsequenzen.

    - Manches tiefe Grundwasser ist uralt, lange vom Rest der Welt getrennt und kein Teil eines Kreislaufs mehr. Diese Brunnen füllen sich nicht wieder auf.

    - Wenn man vor einem leeren oder schmutzigen Brunnen steht tröstet es nicht, dass das früher dort vorhandene Wasser nicht weg, sondern halt im Meer ist.


    Ich vermute auch, dass hierzulande Wasserversorgung noch lange kein Problem sein wird.

    Fördern, verteilen, reinigen braucht einiges an Energie, aber davon ab...

    Anderswo sieht es schlimmer aus.

    - Was ist z.B aus dem Aralsee geworden?

    - Die Gletscher des Himalaja versorgen China und Indien, schmelzen aber "weg".

    - Karge Gebiete haben sich mit vorhandenem Grundwasser eingerichtet, aber das ist irgendwann "weg",

    1. Woher weiß ich, ob das ein Mensch geschrieben hat oder ein Bot? Und falls Du ein Mensch sein solltest: Was hat bei Dir ausgelöst, so eine Betrachtung anzustellen?


    2. Schließe Dich einfach meinem Geschmack und meinen Ansichten an - Problem gelöst! Wenn Du abweichen willst, dann widersprichst Du Deinem eigenen Prinzip.

    Hab mir nun den Code angesehen.

    Was Dir vielleicht nützlich sein könnte:

    - So, wie Du die 4 Sprites gerade nebeneinander stehen hast, kannst Du bequem das Timing austesten. Ist ja alles da: normale Zeilen, Badlines...

    - Ich hab das damals oft mit Unterprogrammen gemacht. Primitiver, langer Code, aber sehr bequem:

    ...Einmal das Timing austesten und ausrechnen, danach lässt sich bequem die ganze Kette von JSRs zusammenfügen.

    - Füll so erstmal den Schirm mit Sprites und mach den Rahmen überall auf.

    - Nicht vergessen, am Ende alle Sprites wieder auf ihre Startposition zu setzen! (lda #50, sta 53249,y...)


    Wenn Du das erstmal hast, dann sehen wir weiter.

    Noch 2 Ideen, wie man drumherum tricksen könnte:


    - Statt dieser Explosionen mehr so Partikelwolken designen, die weniger dicht sind und hoffentlich auch noch gut aussehen, wenn jede 8. Zeile unsichtbar bleibt. Am besten gleich so zeichnen, dass jede 8. Zeile frei bleibt.

    - Die Explosionen könnten die Grafik "zerstören". Wenn erstmal eine komplette Zeile Schwarz ist, dann kannst Du sie durch FLD ersetzen, und dann sind an den Stellen auch keine Badlines mehr.


    Und grad fallen mir noch mehr Sachen auf:

    - Die Grafik oben sieht zwar vom Design her Hires aus, ist aber eigentlich doch nur 160 Pixel, also MC-Auflösung. Dann ist die Farbe nicht ganz so arg beschränkt, wenn man Badlines abschaltet.

    - Ich sehe in dem Beispiel-Bild 8 zufällig verteilte Sprites. Schwebt Dir vor, "einfach nur" den Sideborder bei zufällig positionierten Sprites zu öffnen? Also wenn unendlich viele Rolands unendlich lange in unendlich viele SMONS tippen, dann ist da am Ende bestimmt auch so eine Routine mit dabei... Vergesse es einfach!
    - Stattdessen solltest Du zunächst einen Mulitplexer schaffen, der den ganzen interessanten Teil komplett mit 8 Sprites bedeckt, so vong Rasterzeit her.

    - Tipp: Lasse nicht alle Sprites auf gleicher Höhe starten, also gleiche Y-Position haben. Alle 2 Rasterzeilen das nächste Sprite anfangen lassen.

    - DANN den Sideborder öffnen, DANN zusehen, wie Du die Spriteblöcle im Multiplexer umsetzt und X-Positionen änderst.

    Ich sehe jetzt erstmal keinen Weg, das genau so hinzubekommen.


    Im Bitmap-Modus müsstest Du die Grafik komplett auf reines Schwarz + Weiss oder 2 andere Farben beschränken. Das kann bei passendem Design auch cool aussehen, siehe "Thrust"... Oder halt zu Multicolor wechseln.


    Im Zeichensatz-Modus weiss ich jetzt nicht, wie sich das Badline-Unterdrücken auswirkt.

    Wiederholt es immer die Pixel-Zeile, oder ist der Effekt der wiederholten Char-Zeile auch ohne Badline?So oder so: Die Farbigkeit wäre ebenfalls dahin, und die Grafik wäre auch nur eine simulierte Bitmap, die sich über den ganzen Speicher verteilt. Für Demos ja vielleicht nützlich, aber für ein Spiel irgendwie nicht so.

    Der ändert ja nichts daran, dass während der Datenübertragung CPU in C64 und der 1541 blockiert sind. Wenn ich mich nicht irre, dauert ein 512-Byte-Transfer mit den schnellsten Routinen auf zwei Leitungen gut 10ms, und es geht ja nicht nur um den reinen Transfer, sondern auch das Handshake drumherum; wenn z.B. der C64 ewig warten muss, bis die Floppy mit ihren Rechnungen fertig ist und der Transfer beginnen kann, ist das alles Makulatur.

    Höchstwahrscheinlich nicht. Gründe, die dagegen sprächen, wären

    - Die Datenübertragung zwischen Laufwerk und C64 ist sehr langsam. In der Zeit kann der C64 vieles selber rechnen.

    - Der Speicher der 1541 reicht nicht aus. Zwar wäre u. U. die Datenmenge an sich nicht so groß, aber der Programmcode beträgt mehrere Kilobytes, über die die 1541 nicht verfügt.

    Ja, so etwa 40 Takte, eher mehr je Byte dürften Grenze bei der Übertragung sein. Aber für den Preis bekommt man keine 2 16Bit-Additionen, geschweige denn kompliziertere Berechnungen hin.
    Gefülltes Rechteck von 30*20 Pixel wird in dieser Umgebung kaum unter 1000 zu machen sein und 9 Bytes Zeichendaten brauchen.

    Wenn die Berechnung länger als die Übertragung braucht, dann wird man im Parallel-Betrieb Zeit sparen.


    Mir fehlt ein Gefühl, in welchen Verhältnis die Rechenzeit zur Zeichenzeit in typischen Szenen steht.

    2 KB sind knapp, aber vielleicht dürfen die Rechenroutinen ja langsam sein, weil sie immer noch schneller als das Zeichnen wären?

    Ich behaupte mal das ist keine Bitmap. In der Breite würde das RAM des C64 gar nicht ausreichen. Was da dargestellt wird hat viele wiederkehrende Elemente, das ist ziemlich sicher multicolor character mode. Und das ist ziemlich harmlos zu scrollen ;)

    Der 3. Level mit den Bäumen und Felsen scheint mir dafür sicher zu bunt.
    Im MC-Modus hat man ja nur die ersten 8 Farben als Zeichenfarbe, alle Farben ab Orange(8) müssen MC-Farben sein.
    Und ich sehe da 3 Graustufen in Felsen uns Stämmen, dazu Hellgrün, Orange und Braun in gleichen Rasterzeilen...

    Aber ist das denn auch ein NTSC-Spiel?

    Ich hab da noch einen abwegigeren Gedanken.

    Bedingung für einen Block:

    1) sichbarer Berich,

    2) 1 Abstand =2, der andere Abstand <=2 von der Position der Flagge.


    Äußere Y-Schleife, innere X-Schleife, darin Adresse jeweils um 1 hoch/runterzählen.

    Im inneren der Schleife dann entscheiden, was an dieser Bildschirm-Position gezeichnet werden soll.

    Falls diese Schleife noch für andere Zwecke nützlich sein könnte (Bildschirm löschen? Vielleicht gar andere Elemente kopieren?) KÖNNTE sich das vielleicht lohnen.

    Hoogo : Bei dem zweiten Punkt, was ist das irritierende? Dass die Klammern nicht bevorzugt aufgelöst werden? (Werden sie nämlich bei meinem naiven Parser bei !fill nicht, da wird stur nach Kommata getrennt und dann jeder Ausdruck für sich geparst)

    Der Kontext hier ist vereinfacht, so dass man schnell drauf kommt.

    Im wahren Leben waren jmp und !fill viel weiter auseinander, und das Ziel war in einem Include.

    Da war es weniger einfach, den !fill als Ursache für ganz andere Probleme zu finden.