Beiträge von atomcode im Thema „Regentropfen die an Mühlen klopfen“

    Vielleicht gibt es ja doch noch einen Patch. Zumindest aber ein Video, das den funktionierenden Einbau im Gesamtspiel zeigt, inkl. aller Sprites, also gezogener Kanone, Fadenkreuz und drei seelenlosen Viechern. Da ich eh keinen Quellcode habe, programmiere ich mit dem Freezer-Monitor im laufenden Spiel, das ich dazu erst mal analysieren musste. Die Aussichten sind gut, wenn auch sehr wenig Platz dafür über ist.

    Nochmal das Grundprinzip: Es muss für den Effekt mindestens ein Hardware-Sprite frei sein. Die anderen 7 dürften aber für sonstige Zwecke vervielfacht werden. Vertikal gesehen kann man, bezogen auf einen Frame, bis zu 7 Sprites zusätzlich für den Regen einsetzen, wo sie gerade für ihren eigentlichen Zweck nicht positioniert werden. Das reduziert die Interrupts.

    Sprite-Situation in Hawksmill:

    #0: Waffe, Bitte melde dich an, um diesen Link zu sehen.: Beine, Bitte melde dich an, um diesen Link zu sehen.: Oberkörper, Bitte melde dich an, um diesen Link zu sehen.: Körperfarbe, Bitte melde dich an, um diesen Link zu sehen.: Fadenkreuz oder Mündungsfeuer, Bitte melde dich an, um diesen Link zu sehen.: Vampir 1, Bitte melde dich an, um diesen Link zu sehen.: Vampir 2, Bitte melde dich an, um diesen Link zu sehen.: Vampir 3 oder Wolf. Also alle 8 in Gebrauch.

    Beine und Oberkörper habe ich jetzt auf Sprite Bitte melde dich an, um diesen Link zu sehen. gemultiplext, sodass Sprite Bitte melde dich an, um diesen Link zu sehen. für den Regen frei geworden ist.

    Da diese beiden Körperteile direkt aneinander grenzen, ist das Zeitfenster zum Umschalten sehr klein. Deswegen wird im oberen Rahmen bereits der nötige Zeitausgleich der künftigen VIC-Aktivität bei unterschiedlichem Sprite-Aufkommen derselben Höhe berechnet. Diesen Aufwand kann man sich sparen oder reduzieren, wenn man bei doppelt oder dreifach hohen Figuren gleich eine Zeilenüberlappung von jeweils 1 oder 2 Pixeln einplant.

    Der originale Regen-Task beginnt im unteren Rahmen. Schätzungsweise wird die Sprite-Lösung samt Interrupts nicht mehr Rasterzeilen gebrauchen. Dabei werden im alten Regen nicht mal Zufallstropfen berechnet, sondern einer gespeicherten Zahlenreihe entnommen, sodass sich die Regenanimation ca. alle 1,5 Sekunden wiederholt.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Des weiteren blieben zwei Probleme bei schrägem Regen unberücksichtigt.

    Das größere Problem: Regentropfen, die auf der einen Bildseite ihren Fall mit Aufschlag beenden, fehlen auf der anderen Seite.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das kleinere Problem: Regentropfen, die auf der anderen Seite ein Hindernis an der Bildkante erwartet, schlagen am Nichts auf.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Nächster Schritt: Lokalisieren und löschen von allem, was mit dem Char-Regen zu tun hat, weil ich den Platz brauche.

    Begonnen wird dann mit geradem Regen, und zunächst bis zur Bodenlinie auf der ganzen Breite. Abfrage von höheren Bodenbereichen später.

    Übrigens hat man so auch in Haus und Dungeon ein Sprite frei und könnte damit was machen.

    warum der Hintergrund dann nicht transparent ist.

    Der Zeichen-Hintergrund ist ja transparent. Deswegen sieht man in der Kachel um den Tropfen die allgemeine HG-Farbe. Die Tropfen gehören als Zeichen zum selben Layer wie die anderen Grafikzeichen, schneiden also bei Bit 0 bzw. 00 Löcher in die Grafik, wo die dunkelblaue HG-Farbe zu sehen ist. Der Programmierer und/oder der Grafiker hatten sich für HiRes-Regen entschieden, weil Multi-Char-Regentropfen zu dick sind (sagte er), was durchaus ein Argument ist, vor allem, wenn sie dann noch weiß sind. Man könnte so also auch keine andere Zeichenhintergrundfarbe wählen, außer wenn man das Tropfen-Zeichen invertiert und damit dunkelblaue Tropfen erhält.

    dass die Schüsse [..] so einen blockigen Rand haben

    Womit man übrigens bei TSoH theoretisch noch ein Sprite hätte freimachen können. n zusätzliche freie Sprites können die Interrupts von Sprite-Regen auf 100/(1+n) % reduzieren, also bei einem zweiten Sprite direkt auf nur noch 50%. Und das bedeutet auch, dass vertikal gesehen in den Bereichen, wo nur n diverse Sprites gebraucht werden, lediglich nur 1 Interrupt für 8-n Tropfen-Zeilen nötig ist, was eine zusätzliche Zeitersparnis darstellt.

    wie das mit der Spriteüberlagerung und Transparenz funktioniert. Da kann man wohl einiges tricksen.

    Bei der Spriteüberlagerung braucht man ja nix tricksen; das ist ja automatisch transparent, allerdings als eigener Layer, wo sämtliche Bitmap-/Char-Grafik durch zu sehen ist, sofern sie dahinter ist.

    Übrigens, um die gleiche Anzahl an Tropfen zu erreichen wie gehabt (dann wäre der ursprüngliche Anspruch ja bereits erfüllt), wären mit 1 Sprite nur maximal 10 Interrupts und mit 2 Sprites sogar nur 5 Interrupts nötig. Ein Witz ist das.


    Squidward In TSoH gibt es kein Sprite-Multiplexing. Deswegen berücksichtige ich die Situation bei dem Gebrauch von Sprite-Multiplexing zunächst nicht. Am Anfang stand die Aussage, dass es in diesem Spiel vermeintlich nicht ginge. Wenn das geklärt ist, kann man sich um eine mögliche Anpassung bei Sprite-Multiplexing kümmern, und auch da sehe ich Möglichkeiten, sofern das Multiplexing weniger als 8 Hardware-Sprites verwaltet. Wir schaffen das. [...], not because they are easy, but because they are hard, [...]

    Wie gesagt, am Ende technisch möglich, aber nachträglich blöd zu implementieren...

    Ja, wenn man den Quelltext hätte, wäre vieles einfacher. Dasselbe mit dem Spiel "Rock'n'Roll", falls das nebenan gelesen hast.

    Wenn allerdings bei einer Demonstration des ganzen bereits zu sehen ist oder gemessen wurde, wie viel Rechenzeit benötigt wird, weiß man, wie viel über ist und ob das reicht. Für eine Musik gönnt man sich ja auch bis zu 30 Rasterzeilen. Und diese Routine soll die sein, wie sie in ein Spiel eingebaut werden könnte. Ich bin kein Demoprogrammierer, sondern denke anwendungsorientiert.

    Da zählen andere Sachen meistens mehr und belegen ihren Platz im Rechner.

    Was passiert denn da großartiges, was mehr als 90% der Rechenkapazität schluckt? Klar, in einem anderen Spiel, wo man noch zusätzlich rechenintensive Berechnungen hätte, müsste man sehen, ob man sich den Luxus der Darstellung von Niederschlag leisten kann. Beim Gebrauch von anderweitigem nicht statischen Sprite-Multiplexing würde ich ohnehin eine Char-Variante für Regen vorziehen.

    Bei diesem Spiel hab ich das längst ausgelotet. Wie oben schon geschrieben, braucht die Darstellung mit Sprites gar nicht sooo viel mehr als die vorherige mit den Zeichen.

    Mit "Demo" ist keineswegs eine Demo im üblichen Sinne gemeint, mit Vorausberechnungen, Tabellen und co. (wofür eigentlich? ^^), sondern eine Demonstration der spieletauglichen Implementation des Niederschlags. Und selbst, wenn ich 50% der Rechenzeit bräuchte, was nicht annähernd der Fall sein wird, hätte man noch genug über, um es hier und da (und eben auch bei TSoH) für Außenszenen in adventure-artigen Spielen einbauen zu können.

    Mach doch einen Patch für das Spiel, dann haben alle etwas davon ^^ !

    Voraussichtlich nicht. Du kannst dir sicherlich denken, dass solch ein Eingriff ohne verfügbaren Quellcode nur eine schwierige Frickelei ist. Ich würde aber gern eine Demo, in der der Protagonist mit Wumme und Kugel und die drei angreifenden Viecher und eben der Regen zu sehen ist, samt Quellcode dem Autor zukommen lassen. Und wenn er dann nicht will, dann eben nicht.

    Ich habe außerdem selbst zwei Projekte, die ich idealerweise in diesem Leben noch fertigstellen möchte. Warum ich nicht an die große Glocke hänge, was genau ich da mache, sieht man hier bereits an einem einzigen Teilproblem, denn man ist dann nachher mehr mit Diskutieren als mit Programmieren beschäftigt. Was u.G.W. nicht heißt, dass ich Schuldige suche! Das ergibt sich einfach so, hat vllt. teilweise sogar was mit Sucht zu tun. Dieses Internet ist Fluch und Segen zugleich; ihr wisst schon. Was waren das Zeiten, wo mein Buch "Alles über den C64", jede Seite geziert mit Kaffeespuren, neben mir lag und ich viele Stunden am Stück am Coden oder Malen war, ohne mich dauernd mit irgendwelchen Smart- und Inter-Systemen abzulenken oder bei jedem umgefallen Sack Reis nachlesen zu müssen, was da los ist. Andererseits möchte man bei Nutzung des Internets und eines Forums ja auch nicht nur als "Leecher" dastehen.

    Hmm jetzt sieht es eher aus wie Meteoritenschauer.

    Was wohl daran liegt, dass man den Regen in dem Modus (wie im Video) eben als weit entfernten Regen interpretiert, und dann müsste er dichter und dunkler sein. Vorher verstand man ihn als den Regen direkt um einen herum, und dafür passt die Dichte dann schon eher, wobei Weiß für Regen immer noch zu hell ist. Genau genommen ist Regen weitgehend durchsichtig, weil's ja Wasser ist, und man sieht nur Spiegelungen und Brechungen. Wenn es dunkel ist, sieht man Regen in der Ferne fast gar nicht, was dem Fehlen etwaiger Parallax-Tropfen entgegenkommt. Also ist es nicht wie mit simulierten Sternen bei "Wahnsinniger Geschwindigkeit"®, die man bekanntlich auch aus großer Entfernung gut sieht, weil sie im Gegensatz zu Regentropfen selbstleuchtende Körper sind. Das ist damit gemeint, sich an Realismus zu orientieren, ohne dass man gleich darüber lachen muss, beim Entwickeln für 8-Bitter das Wort Realismus in den Mund zu nehmen.

    ===

    wie du aus einem Sprite 30 machst

    Hatte ich nirgends behauptet. Hatte es stattdessen sogar noch vorgerechnet.

    ---

    allein das geht schon nicht

    aha, noch einer. Bitte mehr davon, dann macht das Umsetzen erst richtig Spaß. :)

    ---

    u. dann v.a. noch nicht alle Rasterzeit für den Rest dies Spiels komplett verbrauchst

    Das braucht kaum mehr als das vorherige System. Man braucht keine komplizierten Berechnungen dafür. Die Pseudozufallszahlen bspw. entspringen einem ultraschnellen Schieberegister, eine handvoll Zyklen pro Frame.

    ---

    ohne dass die "eigentlichen" Sprites (u. auch die Regentropfen in selber Zeile -weil ja nur ein Sprite-) ständig wie verrückt flimmern weil der Regen nicht nur partiell über den Bildschirm sondern über den kompetten und somit die Zeilen aller Sprites ständig kreuzt). So einfach ist das sicher nicht, bis auf das Flimmern meinetwegen wenn man es richtig timed. Aber dann flimmern sicher immernoch zumindest die R.-Tropfen in selber Zeile mit nur einem Sprite.

    Da flimmert überhaupt nichts, weil der Regen ein eigenes Sprite bekommt, sagte ich aber schon.

    und zwei Sprites lassen sich bei dem Spiel frei machen, ohne auf etwas verzichten zu müssen.

    Habe die Sprite-Verteilung bereits überprüft und festgestellt, dass es ohne Abstriche geht.

    ---

    Kannst den einen Spritetropfen ja auch erst ab jeder Tropfengöße vertikal erneuern, so dass nichts in selber Zeile dargestellt werden muss.

    50 fps und nie mehr als 1 bzw. 2 Sprites nebeneinander, problemlos realisierbar. Die Lösung, die in der Videobeschreibung steht, ist noch nicht dabei, also nur 1 Sprite, das teils einen, teils zwei Tropfen darstellt (so kommt man auf 30 = 1,5 Tropfen * ca. 20 Zeilen).

    ---

    Dann aber dürfte der Regen etwas zu spärlich aussehen, mengenmäßig.

    30 Tropfen gleichzeitig können nicht spärlicher aussehen als die 10 in dem Spiel. Nach Adam Ries ist das dreimal so dicht.

    Dass jeder Tropfen/Topfenpaar eine eigene Höhe hat, bemerkt der Betrachter normalerweise gar nicht. Da muss man schon anhalten und ein Lineal dran legen, va. wenn sie weit auseinander liegen. Und die, die nicht weit auseinander liegen, haben ja teilweise dieselbe Höhe, weil sie im selben Sprite liegen. Aber selbst in einem echten Regen haben zwei Tropfen nie exakt dieselbe Höhe.

    Ne ne, passt schon der Titel, ist doch witzig. "Wetter-Simulation" ist ja auch etwas weit hergeholt. Erst wollte ich "meteorologische Simulation" schreiben, klingt aber noch dicker aufgetragen. ^^

    an Realismus orientierter Grafik

    Diese smarte Formulierung trifft es sehr gut.:emojiSmiley-106: Ich sprach schon mal hier irgendwo von "realistischere Darstellung" in einem Satz mit "C64" (ich glaube, es ging um Farben), und da lachte jemand drüber, offenbar eben wegen der bekannten Grenzen der alten Rechner. Aber ganz genau, bei Null angefangen, kann man dennoch versuchen, dem Natürlichen so weit es geht entgegen zu kommen, sich also mit den gegebenen Möglichkeiten am Realismus zu orientieren, egal ob es die Physik, das Aussehen oder der Sound ist. Klar, vom wirklich realistischen Simulieren bleibt man da weit entfernt.

    Niederschlag oder ähnliche Effekte wie Laub (in "L'Abbaye des Morts" zu sehen), Pollenflug über der Wiese oder aufsteigende Blasen unter Wasser, welche ein Umgebungsgefühl vermitteln sollen, sind ja für 8-Bitter schon ziemlicher Luxus, aber lohnen sich, wenn es das wert ist, damit die Spielatmosphäre zu verstärken.

    Ob Regentropfen oder andere Partikel, das Prinzip bleibt ja eh das gleiche. Nur Grafik und Bewegungen ändern sich. Darum kann man sich erst mal auf Regen beschränken, und das scheint ja auch gerade aktuell zu sein. Eine Demo werde ich jedenfalls machen. Habe die Sprite-Verteilung bereits überprüft und festgestellt, dass es ohne Abstriche geht.

    Wundert mich dann aber, dass die Programmierer es schaffen, solch ein tolles Game zu programmieren, aber diese Sache mit dem Regen dann nicht besser lösen können, wenn es, wie du schreibst, machbar ist.

    Spieldesign und -idee oder die technische Umsetzung des ganzen sind eben zwei paar Schuhe. Manche teilen sich deswegen diese Aufgaben, wo der eine sagt, ich möchte da dies und das haben und dann soll da jenes und solches passieren und ungefähr so und so aussehen, und ein anderer, der hauptsächlich aufs Technische fixiert ist, sieht zu, mit Hilfe seines fundierten Knoff-Hoffs das so hinzubekommen. Dieses Spiel lebt vom Design und nicht von der Technik. Allein die Aussage des Programmierers, dass er "alles" ausprobiert habe, aber das dann noch schlimmer ausgehen hätte, zeigt, dass es seine eigenen Grenzen waren und nicht die des C64 (sieht ein blauer Tropfen auf schwarzem Grund wirklich schlechter aus als ein weißer mit blauem Kasten drumherum? wohl kaum).

    Was ja alles auch überhaupt nicht schlimm ist; immerhin hat er sich noch ums Abschalten gekümmert. Das kann ich alles problemlos akzeptieren. Was ich aber eben nicht richtig finde, ist, dies dann immer auf die Hardware zu schieben, sodass nicht so programmier-erfahrene User denken müssen, der C64 ist der hintervorletzte Schrottcomputer, der ja nicht mal Regen darstellen kann. :cursing: Bullshit.

    Ich werde es kaufen, nicht weil ich es spielen will, sondern um gescheiten Regen einzubauen (als Demo, weil ich keinen Quellcode habe). Eigentlich habe ich zwar anderes zu tun, aber solche Aussagen von wegen "geht nicht" lassen mir keine Ruhe. Aber ich weiß schon, was dann kommt .. "viel zu kompliziert, mimimi". Und das schlimmste ist, dass man so etwas gar nicht mal tun darf, denn der Autor meint, dass Feedback, das nicht 100% positiv ist, die Lust am Programmieren verdirbt. Er bestätigt auf Facebook: Hätte man früher schon die heutige Möglichkeit für Feedback gehabt, wären nur wenige Spiele durchgekommen, und der kreative Einsatz der Programmierer wäre auf der Strecke geblieben, "it's very draining and can really piss you off". Mit anderen Worten, ab sofort nur noch Lobeshymnen und bitte niemals Kritik oder Verbesserungsvorschläge.

    Ein Beispiel (Spiel oder Demo)?

    Sternensimulationen, oft mit Parallax-Effekt, gibt es zuhauf und ist auch nichts anderes. Eine(s) speziell für Regen weiß ich jetzt nicht auswendig, da ich weniger Konsument bin. Aber ich muss auch nicht erst ein Beispiel sehen, wenn ich genau weiß, wie es geht. Ist ja noch nicht mal 'ne Raketenwissenschaft das ganze. Mit Zeichen geht es auch, aber komplizierter und nicht so schön wie mit einem Sprite. Das ist aber dann sinnvoll, wenn man unbedingt alle Sprites für andere Zwecke benutzen will. Dafür gibt es dann verschiedene Ansätze, vom Kopieren und Ausstanzen von Chars bis zur Speicherung einer Tropfenhintergrundfarbe pro Zeichen.

    btw Ein Mod darf den Off-toppic-Salat gern auslagern. "Wetter-Simulation in C64-Spielen" z.B. :) Denn da kann man noch länger und genauer drüber, natürlich auch ohne sich auf ein bestimmtes Spiel zu beziehen. Es geht ja nur um die technischen Möglichkeiten.

    Hier habe ich auf die Schnelle mal eine Simulation der Simulation gemacht. 50 fps und nie mehr als 1 bzw. 2 Sprites nebeneinander, problemlos realisierbar. Die Lösung, die in der Videobeschreibung steht, ist noch nicht dabei, also nur 1 Sprite, das teils einen, teils zwei Tropfen darstellt (so kommt man auf 30 = 1,5 Tropfen * ca. 20 Zeilen). Außerdem kann man die Linien im Sprite dünner und länger machen. Da das Spiel, dessen Name in diesem Zusammenhang nicht genannt werden darf, noch nicht mal Multiplexing verwendet, ist dabei die Realisierung besonders einfach. Musik kann ab Fußboden beginnen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

    EDIT by FXXS:Threadsplit und dafür Zitat erweitert.


    Es geht um die Regentropfen in
    "Shadow over Hawksmil".

    In der V2 Version des Spiels haben sie jetzt auch diese Sache mit dem etwas komisch aussehenden Regen behoben. Leider sieht man jetzt dafür aber wieder die Regentropfen nur hinten den Gebäuden runterkommen und nicht mehr wie sie auf dem Boden aufkommen. Auch wieder bisschen schade, aber ging wahrscheinlich technisch nicht anders zu machen, entweder der Charset-Regen mit den Vierecken drumherum oder eben wie es jetzt ist, der Regen nur im Hintergrund.

    Natürlich geht das. Nur, weil einer etwas nicht machen will oder kann, muss man doch nicht sagen, dass dies schon die Grenzen des C64 sind. Es gibt Lösungen für den Char-Mode, für Bitmap-Mode, der bei Flipscreen-Games übrigens auch geht, und am besten und schönsten geht es mit Sprites. Ein einziges reicht schon, um dreimal (30) so viele Tropfen gleichzeitig regnen zu lassen wie aktuell (10), und zwei Sprites lassen sich bei dem Spiel frei machen, ohne auf etwas verzichten zu müssen.