Re: Trackermodul-Engine (sehr einfach)
Verfasst: Mi 5. Okt 2016, 17:44
Ziemlich verspätet nun noch ein paar Antworten an DOSferatu:
anderer schon hatte), hatte ich schon früher:
Statt mit Hintergrund komplett wieder drüber kopieren und Pufferung könnte man
sich vielleicht merken bzw. bestimmen, welche Bildschirmbereiche von
einem Sprite überdeckt sind und bei Umpositionierung des Sprites,
welche Hintergrundbereiche wieder frei werden.
Und dann eben nur immer das "umzeichnen" was sich wirklich verändert hat.
Ist bei der praktischen Umsetzung wahrscheinlich langsamer und aufwändiger
als die Puffer-Neuzeichnen-Methode, aber ein Gedanke daran kostet ja nix.
Allerdings wäre diese Idee vielleicht eine mögliche Lösung bei zu langsamem
Datendurchsatz der VGA Karte.
Ich glaube, das war zu meinen BASIC-Zeiten mein erster Gedankenanstoß, wie
bewegte Grafik vor Hintergrund machbar wäre. In QBasic war Bildschirmpufferung
nicht ohne weiteres möglich (Datenfelder insgesamt max. 64K meine ich) -
aber ohne Assembler ist so eine Idee natürlich erst recht nicht umzusetzen.
Ich finds ganz interessant, werd mal drüber nachdenken, ganz egal ob ich
dann früher oder später merke dass es vielleicht Blödsinn ist.
Pixel auch z.B. an der x-Koordinate 316 darstellen kann, und dann eben nur die
ersten 4 senkrechten Zeilen dargestellt werden sollen und der Rest abgeschnitten.
Ebenso oben, unten, und links. Das ist mit simplen Sprites einfach, aber in so
einem komplexen Gefüge, aus 8x8 großen Blöcken mit jeweils unterschiedlichen
Bit-Tiefen zusammengesetzt, und dabei auch noch je nachdem bei gleichen
aufeinanderfolgenden Blöcken mit blockweiser Lauflängenkodierung, das überfordert mich erstmal.
demonstriert - habe einfach die Transparenzoption von ZVID genutzt, erster Frame komplett,
die anderen transparent und nur gespeichert was sich verändert hat.
Aber man kann ZVID natürlich auch nicht als Delta verwenden.
Also einfach statt der bildschirmfüllenden Frames, Sprites verwenden, die trotzdem
noch eine gute Kompression erfahren würden, auch weil ich in dem Format redundante
Blöcke berücksichtige, d.h. wenn z.B. bei Sprites der Kopf immer gleich bleibt, dann
wird dieser Bereich nur einmal gespeichert und fortan nur indiziert.
Leider aber kriege ich das vorerst nicht mit dem Clipping hin, ich kann also ZVID
nur für Hintergründe bzw. für "Level-Steine" benutzen, oder eben für Sprites in
einem Spiel wo die Sprites niemals über den Bildschirmrand hinausgehen.
Ich kann mich an deinem Musikprogramm gerne mal versuchen, allerdings tue
ich mich schwer mit Benutzerinterfaces die anders sind als die von meinem
Tracker, der im Borland-Stil gehalten ist.
Ich habe übrigens noch ein paar Basic-Spiele, die bis 1992 zurückgehen,
aber alles schon mit 256 Farben VGA Grafik. Die habe ich nur bisher nicht
präsentiert, weil sie auf einem 286er konzipiert wurden und natürlich auf
späteren Rechnern zu schnell liefen. Aber in dosbox lässt sich das ganz
gut regeln.
Ich habe es nicht genau durchgedacht, aber die Idee (die sicher auch manchDOSferatu hat geschrieben: Auf C64 konnte man sich ja auf die Hardware-Sprites verlassen - da mußte man keinen "Hintergrund löschen".
anderer schon hatte), hatte ich schon früher:
Statt mit Hintergrund komplett wieder drüber kopieren und Pufferung könnte man
sich vielleicht merken bzw. bestimmen, welche Bildschirmbereiche von
einem Sprite überdeckt sind und bei Umpositionierung des Sprites,
welche Hintergrundbereiche wieder frei werden.
Und dann eben nur immer das "umzeichnen" was sich wirklich verändert hat.
Ist bei der praktischen Umsetzung wahrscheinlich langsamer und aufwändiger
als die Puffer-Neuzeichnen-Methode, aber ein Gedanke daran kostet ja nix.
Allerdings wäre diese Idee vielleicht eine mögliche Lösung bei zu langsamem
Datendurchsatz der VGA Karte.
Ich glaube, das war zu meinen BASIC-Zeiten mein erster Gedankenanstoß, wie
bewegte Grafik vor Hintergrund machbar wäre. In QBasic war Bildschirmpufferung
nicht ohne weiteres möglich (Datenfelder insgesamt max. 64K meine ich) -
aber ohne Assembler ist so eine Idee natürlich erst recht nicht umzusetzen.
Ich finds ganz interessant, werd mal drüber nachdenken, ganz egal ob ich
dann früher oder später merke dass es vielleicht Blödsinn ist.
Ja, es geht einfach darum, dass man ein Sprite von einer Breite von sagen wir 16DOSferatu hat geschrieben:[...ZVID clipping...] Ich weiß nicht, was Du in diesem Zusammenhang mit Clipping meinst. Betrifft das das "Verhalten am Bildrand" (z.B. bei halb-gescrollten "Kacheln")?
Pixel auch z.B. an der x-Koordinate 316 darstellen kann, und dann eben nur die
ersten 4 senkrechten Zeilen dargestellt werden sollen und der Rest abgeschnitten.
Ebenso oben, unten, und links. Das ist mit simplen Sprites einfach, aber in so
einem komplexen Gefüge, aus 8x8 großen Blöcken mit jeweils unterschiedlichen
Bit-Tiefen zusammengesetzt, und dabei auch noch je nachdem bei gleichen
aufeinanderfolgenden Blöcken mit blockweiser Lauflängenkodierung, das überfordert mich erstmal.
Dieses Delta-Feature hat ZVID nur nebenbei. Ich habe damit nur die KompressionsratenDOSferatu hat geschrieben: Also für etwas, das keine Animation ist, sondern etwas interaktives, sind so "Delta-Film" artige Animationsformate meiner bescheidenen Meinung nach eher weniger geeignet.
demonstriert - habe einfach die Transparenzoption von ZVID genutzt, erster Frame komplett,
die anderen transparent und nur gespeichert was sich verändert hat.
Aber man kann ZVID natürlich auch nicht als Delta verwenden.
Also einfach statt der bildschirmfüllenden Frames, Sprites verwenden, die trotzdem
noch eine gute Kompression erfahren würden, auch weil ich in dem Format redundante
Blöcke berücksichtige, d.h. wenn z.B. bei Sprites der Kopf immer gleich bleibt, dann
wird dieser Bereich nur einmal gespeichert und fortan nur indiziert.
Leider aber kriege ich das vorerst nicht mit dem Clipping hin, ich kann also ZVID
nur für Hintergründe bzw. für "Level-Steine" benutzen, oder eben für Sprites in
einem Spiel wo die Sprites niemals über den Bildschirmrand hinausgehen.
Ich kann mich an deinem Musikprogramm gerne mal versuchen, allerdings tue
ich mich schwer mit Benutzerinterfaces die anders sind als die von meinem
Tracker, der im Borland-Stil gehalten ist.
Ich habe übrigens noch ein paar Basic-Spiele, die bis 1992 zurückgehen,
aber alles schon mit 256 Farben VGA Grafik. Die habe ich nur bisher nicht
präsentiert, weil sie auf einem 286er konzipiert wurden und natürlich auf
späteren Rechnern zu schnell liefen. Aber in dosbox lässt sich das ganz
gut regeln.