Fullsize-Bitmap Scroller mit X+Y + Ebenen ... Tips(?)

ThoralfAsmussen · 7. August 2023

Zitat von Mathias

Ich verfolge das Forum zwischendurch.
Was mir dabei auffällt, es kommen fast keine Posts, was die Programmierung angeht.
Ich hätte da eher das Gegenteil erwartet, das es ein Reiz sein kann Software für eure Museum-Computer zu entwickeln.

Ist somit Notalgie programmieren keine gefragte Sache ?

Ich habe mir das mal zu Herzen genommen und was probiert, was ich auf normaler klassischer Hardware nie hinbekommen habe / würde.

demo2-mp4.zip <= Film der Animation als mp4

Aber vielleicht gibt es ja ein paar Tips, was man auf einem - sagen wir mal Atari, Archie, Mac - macht, um etwas in der Art hinzubekommen.

Hier im 'Versuch' werden einfach kleine Bildchen mit Transparenz nebeneinander gemalt und das in drei Ebenen. Sowas gibt es aber auch schon auf Rechnern, die überhaupt nicht wissen, was Farbtransparenz überhaupt sein soll. Zum Beispiel im Xzentrix Demo von 1994

https://www.youtube.com/watch?v=NNWzZlgIjCI&t=79s

und butterweich scrollt es da auch noch ...

In "statisch" und "schön" als Wallpaper gibt es das auch

pattern, geometry, hexagon, minimalism, simple background | 1920x1080 Wallpaper - wallhaven.cc

pattern, geometry, hexagon, minimalism, simple background | 1920x1080 Wallpaper

wallhaven.cc

Mathias · 7. August 2023

Auf einem heutigen Rechner würde ich die mit OpenGL lösen.

Wen ich mich richtig erinnere, hatten alte PCs wie der C64 nicht Hardware-Sprite ?

Norbert-97801 · 7. August 2023

Zitat von Mathias

wie der C64 nicht Hardware-Sprite ?

Ja, hat er. Und mit einer pfiffigen Programmierung kannst du mit dem Rasterzeilen Interrupt die Sprite-Positionen und Speicherbereiche im "Multiplex-Artigen" betrieb ändern, so das aussieht, als ob der C64 z.B. 32 Sprites hätte... ... in Wirklichkeit hat er "nur" 8 davon.

ThoralfAsmussen · 7. August 2023

Zitat von Mathias

Auf einem heutigen Rechner würde ich die mit OpenGL lösen.

Gute Idee. Wahrscheinlich, aber da braucht s dann sinnvollerweise auch passende Hardware dazu, sonst mach das auch nur "halb" Sinn. Und Mesa ist jetzt nicht so die Erfüllung - v.a. auf einem 8Bit oder AtariST.

Infos zu 64er Sprites gibt es in aller Ausführlichkeit bei

Sprite – C64-Wiki

aber

Zitat von Norbert-97801

kannst du mit dem Rasterzeilen Interrupt die Sprite-Positionen und Speicherbereiche im "Multiplex-Artigen" betrieb ändern, so das aussieht, als ob der C64 z.B. 32 Sprites hätte

das ist wohl schon eher die hohe Kunst ...

Außerdem vermute ich, daß man auch mit 8 Sprites bei 24x21 Pixel nicht 3 Ebenen hintereinander bildschirmfüllend bekommt.

Trotzdem ist auch das ja schon wieder was, was dann nicht überall machbar ist - ohne Sprites nix los , wie es der C16 Owner zu sagen pflegte.

Bin aber eh grad am Überlegen, wie man nicht evtl. eher bißchen Farbigkeit in die "neue Variante" hineinbekommt. Sowas müßte eigentlich auch ein super Effekt für solche gepackten Demos ala farbrausch sein, weil man letztlich nicht vielmehr als 3 Trapeze benötigt aus denen man alle Hexagone zusammenbasteln kann, und für die hinteren Ebenen muß man halt die Koordinaten "stauchen".

gymfan · 7. August 2023

Zitat von ThoralfAsmussen

Außerdem vermute ich, daß man auch mit 8 Sprites bei 24x21 Pixel nicht 3 Ebenen hintereinander bildschirmfüllend bekommt.

So lange es nur um die Nachprogrammierung des Videos geht, sind eher die 4 Farben das Problem. Selbst in den 64 KB des C64 dürften sich genügend Spritdaten unterbringen lassen, um die sich immer wiederholdenden Bewegungen damit statisch vorberechnen zu können. Sobald es aber mehr wie 2 Farben in einer Zeile werden sollen (was hier ja der Fall ist), muss man irgendwas mit MultiColor machen und landet bei effektiv 160x200 Pixeln.

Bei geschickter Programmierung und Zyklenabzählung mag man es sogar schaffen, mehr wie 8 Sprites in einer Zeile darzustellen. Das läuft dann halt nur noch auf einem PAL oder NTSC C64.

Wobei ich hier garnicht mal auf Sprites gehen würde, sondern auf Mulit-Color Zeischensätze. Horizontal kann der C64 pixelweise per HW scrollen (bis zu 7 Pixel), danach und/oder für das vertikale Scrollen müsste man entweder den Textspreichen während dem Bildwechsel neu füllen oder den Zeichnsatz zum richtigen Zeitpunkt umschalten.

Lustig wird es erst, wenn man das ganze nur als Beiwerk zum Spiel programmieren wollte. So ähnlich wie bei Sonic für den C64 mit dem Scrolling in alle 4 Richtungen plus Gameplay:

https://www.youtube.com/watch?v=jGp4a00OeRs

Aber gut, da wird auch die REU (Speichererweiterung) benötigt, da nur diese den Speicher schnell genug kopieren kann.

Zitat von ThoralfAsmussen

Trotzdem ist auch das ja schon wieder was, was dann nicht überall machbar ist - ohne Sprites nix los , wie es der C16 Owner zu sagen pflegte.

Jede Lösung für einen retro-Computer ist eine höchst individuelle Lösung. Von daher wird auch die im Video gezeigte Demo einzig auf dem Acorn A3000 laufen, u.U. noch auf Schwestermodellen mit annähernd gleicher HW. Ich weiss aber nicht, was der A3000 u.U. am HW-Unterstützung liefert. Wenn der ein HW Blitting von Speicher kann, könnte man ein passendens Teilbild zuvor berechnen und das live immer an die passende Stelle kopieren.

Beim C64 würde man dafür, wie oben bei Sonic, die REU benötigen, das Kopieren mit dem 6510 ist m.W.n. dafür zu langsam.

Zitat von Mathias

Auf einem heutigen Rechner würde ich die mit OpenGL lösen.

Auf einem heutigen PC würde ich die gesamte Grafik einfach als 2D-Bitmap generativ im Hintergrund erzeugen. Am Einfachsten durch drei kleine Bitmaps, jeweils eine pro Ebene mit transparentem Hintergrund, welche man 60 mal pro Sekunde in den Backbuffer kopiert und das ganze per Double Buffering anzeigt.

Man müsste noch nicht einmal den gesamten Bildschirm auf diese Weise zeichnen, sondern nur den passenden Ausschnitt, den man X mal in den Backbuffer kopiert.

Für so meine Aktion benötigt man auch keinen aktuellen Rechner, das müsste selbst mein alter Atom-Netbook von 2009 hinbekommen, da selbst dessen Grafikeinheit (wenn man sie so bezeichnen möchte) GDI (also Teile von 2D-Befehlen für Wnidows in HW) beherrscht.

Unter Linux wäre ich dann eher bei SDL, oder was da heutzutage an 2D-Grafikpaketen üblich ist. 2D mit OpenGL hat mir zumindest früher nicht wirklich Spaß gemacht, aber u.U. sind die aktuellen Versionen auch besser geworden.

Mathias · 8. August 2023

Zitat

Unter Linux wäre ich dann eher bei SDL, oder was da heutzutage an 2D-Grafikpaketen üblich ist. 2D mit OpenGL hat mir zumindest früher nicht wirklich Spaß gemacht, aber u.U. sind die aktuellen Versionen auch besser geworden.

Ich ging vom 2. obersten Bild aus, welches noch beleuchtet ist. Pro Ebene ist nur ein Rechteck mit einer Textur Alphablending Textur von nöten.

Und dann noch die passende Beleuchtung. Ich würde trotzdem 3D nehmen. Die 3 Ebenen in verschiedenen Z Abständen.

Ich habe gerade das Bild nochmals genauer betrachtet. Das Bild ist 3D, ausser es wurde bump mapping verwendet.

Was bei OpenGL noch dazu kommt, das Bild einmal rendern und dann nur noch Koordinaten verschieben.

eto · 8. August 2023

Zitat von ThoralfAsmussen

Aber vielleicht gibt es ja ein paar Tips, was man auf einem - sagen wir mal Atari, Archie, Mac - macht, um etwas in der Art hinzubekommen.

Also das, was da als MP4 angehängt ist, sollte mit Bitplanes auf dem ST ganz gut hinzubekommen sein. Auf dem ST hast du 4 Bitplanes und wenn jede als 1 Layer fungiert, dann bekommst du die 4 Ebenen mit je einer Farbe. Ich hab das in den frühen 90ern mal programmiert, das sah schon nett aus.

MarkL · 9. August 2023

Ich schreibe mal für den Amiga. Die Y-Position der einzelnen Planes ist nicht das Problem. Fürs X bräuchte man der Einfacheit halber Hardwarescrolling. Das gibt es nur für gerade und ungerade Planes separat. (Möglicherweise auch nur im Playfieldmodus, der 2+ Planes zusammenfasst.) Der Blitter sollte das für die eine dritte Plane mit Doublebuffering schon noch schaffen. Ab 020er CPU lohnt sich das aber wohl nicht mehr. Ziel ist jetzt 3 Ebenen oder 4 in 320er Auflösung horizontal? Sehe das hier im Film auf dem Handy nicht so gut.

Der Archie ist wegen der RISC Architektur und dem linearen Chunky Pixel Mode da im Vorteil, deshalb sieht das Demo aus den 90ern auch so überagend gut aus, nicht nur 1-farbig je Ebene. Letzten Endes gibt es sicher eine kleinstmögliche Kachel, die zigfach repliziert wird. Die Bewegung darf vordefiniert und nicht völlig frei sein?

ThoralfAsmussen · 9. August 2023

Zitat von eto

Auf dem ST hast du 4 Bitplanes und wenn jede als 1 Layer fungiert, dann bekommst du die 4 Ebenen mit je einer Farbe.

Das stimmt. An Bitplanes habe ich noch gar nicht gedacht. Da macht sich sowas ja nochmal ganz anders. Vor allem, wenn es hardwarebeschleunigt gemalt werden kann.

Irgendwie hatte ich nie so ein Bitplane Gerät, weshalb mir das Konzept immer noch komisch vorkommt, dabei war es doch eigentlich mal "state-of-the-art" der Computergrafik.

Zitat von MarkL

Ziel ist jetzt 3 Ebenen oder 4 in 320er Auflösung horizontal?

Auflösung ist nicht vorgegeben. Mein Demoversuch läuft mit 1152x864 (ist nur im Video runterskaliert) und 32bit Farben. Ist aber natürlich wohl außer Konkurrenz.

3 Ebenen sind sicherlich Minimum, weil weniger den Effekt gar nicht bringt. Mehr dürfen es auch sein, aber es wird wohl einfach dann auch nicht mehr erkennbar, was in der 7ten Ebene passiert. Also laß mal bei 3 Ebenen, das paßt dann schon.

Zitat von MarkL

Der Archie ist wegen der RISC Architektur und dem linearen Chunky Pixel Mode da im Vorteil, deshalb sieht das Demo aus den 90ern auch so überagend gut aus, nicht nur 1-farbig je Ebene. Letzten Endes gibt es sicher eine kleinstmögliche Kachel, die zigfach repliziert wird. Die Bewegung darf vordefiniert und nicht völlig frei sein?

Ja das denk ich auch, daß das gekachelt ist. Möglicherweise wird es auch einfach direkt im Bildschirmspeicher vervielfacht - d.h. die erste Kachel wird "passend" gesetzt und der Rest dann einfach in X-Y nach rechts und unten umkopiert. Zumindest wäre das was, was der ARM gut kann, wenn man nämlich immer die Register füllt und dann an alle passenden Positionen schreibt. Das spart jede Menge Lesezugriffe.

Die Bewegung darf gern auch vordefiniert sein. Ich glaube aber nicht, daß das ein wesentlicher "Powerfresser" ist. Ich habe einfach eine Lissajous Bewegung mit der das die Ursprungspunkte der jeweiligen Plots noch modifiziert (aufaddiert).