Hello, Guest the thread was called691 times and contains 19 replays

last post from v3to at the

CPC Bitmap-Grafik

  • Ich habe gerade ein paar Specs bzgl. der CPC Bitmap-Grafik (ohne Plus) überflogen und wollte hier nachfragen, ob ich das soweit richtig verstanden habe:


    Mode 0: 160×200 pixels with 16 colors

    Mode 1: 320×200 pixels with 4 colors

    Mode 2: 640×200 pixels with 2 colors


    Overscan Mode:

    Full screen Mode 0: 192×272 pixels with 16 colors

    Full screen Mode 1: 384×272 pixels with 4 colors

    Full screen Mode 2: 768×272 pixels with 2 colors


    Farbpalette: 27 Farben (3 Level RGB)


    Keine Hardware-Sprites, sodass sich die Software-Sprites die Farben mit dem Hintergrund teilen.


    Und jetzt kommt's: Keine weiteren Einschränkungen (je Zeile, Block oder irgendwas)? Ich kann also ganz normal ein "Multicolor"-Bild (C64-sprech) mit (Overscan savezone) 192 x 256 Pixeln und 16 (aus 27) Farben malen und müsste nichts weiter bedenken? Und ich könnte die gleichen 16 Farben in allen Software-Sprites nutzen? Das wäre ja krass (im Vergleich zur damaligen 8-Bit-Konkurrenz).


    Jetzt die nächste (wahrscheinlich ernüchternde) Frage: Wieviel Software-Sprites (sagen wir mal in 24x24 oder 16x16 Pixeln Auflösung) (oder wieviele Pixel insgesamt) könnte man denn in einem Spiel mit 50/60 fps realistischerweise (natürlich in Assembler) über den Bildschirm bewegen?

  • Die von anderen 8-Bit Systemen bekannten Einschränkungen bezüglich der Farben gibt es beim CPC nicht.

    Jedes Pixel kann jede Farbe annehmen, entspechend der Anzahl die im jeweiligen Mode möglich sind.

    Erst der Programmierer hat sich mit der etwas komplizierten Farbkodierung auseinander zu setzen.


  • Alles wichtige über den CPC ist auf https://k1.spdns.de/Vintage/Sc…C%20Systembuch/index.html zu finden.

    Ich habe aber keine Lust, ein ganzes Buch zu lesen, um meine eine Frage beantwortet zu bekommen – zumal ich eher davon ausgehe, dass die Antwort dort nicht drinsteht. Ich möchte wissen, wie viele bzw, wie große Objekte ich je Frame über den Bildschirm bewegen kann, also wie Action-tauglich der Bitmap-Mode ist.

  • Ich möchte wissen, wie viele bzw, wie große Objekte ich je Frame über den Bildschirm bewegen kann, also wie Action-tauglich der Bitmap-Mode ist.

    Schwierige Frage und kommt darauf an was für ein Spiel/Demo es sein soll.

    Beim CPC ist z:B. das Scrolling nicht so leicht zu bewerkstelligen wie Du es

    vom C64 kennst und abhängig von den Fähigkeiten des Programmierers.

    Daher spielen eine Menge Faktoren eine Rolle wie viel Bewegung auf dem

    Bildschirm machbar ist. Vielleicht kann M. J. was dazu schreiben. Der hat

    auf dem CPC schon einige hinbekommen und kann da eine qualifiziertere

    Antwort geben.

  • Beim CPC gibt es eigentlich nicht viel zu berücksichtigen, wenn man dort Grafik erstellt. AFAIK basiert die Grafik auf CGA, ist aber flexibler als beim PC, wobei die Freiheit bei der Farbpalette und Mode 0 mit 16 Farben schon ein echtes Highlight darstellen. Ist halt alles rein Bitmap, es gibt keinen Charmode und auch keine Sprites. Der Umstand ist halt, dass die Kiste aufgrund der fehlenden Beschränkungen bei der Grafik allgemein nicht gerade ressourcenschonend ist.

    Soweit ich weiß unterstützt der CPC von Haus aus Scrolling, bekommt aber wohl auf herkömmliche Weise nur vertikales Softscrolling hin und horizontal in 4x8-Pixelblöcken. Der CPC ist für bestimmte Darstellungen sicher besser geeignet als der C64, wie zb isometrische Spiele oder halt auch Games mit Flipscreen und überwiegend statischer Grafik. Wobei ich denke, dass wenn man zb Bomb Jack DX portieren wollte, muss man sich vermutlich auf 25 fps einstellen.

    So Referenzspiele zur Einordnung, was mit dem CPC so geht, wären mMn als Beispiel für Mode 0 Gryzor, Purple Saturn Day, Super Cauldron, Pinball Dreams, Get Dexter, Chase H.Q oder Xyphoes Fantasy. Für Mode 1 Head over Heals.

  • Das wäre ja krass (im Vergleich zur damaligen 8-Bit-Konkurrenz).

    Das war auch "krass". Was die "stehende Grafik" anging, stand der CPC damals ganz oben mit dabei.

    The Amstrad CPC is perhaps the only cheap personal computer of this generation with absolutely no such thing as (character) colour attributes.

    Auf dieser französischsprachigen Seite sind einige Screenshots zu den verschiedenen Modi zu finden. Auch wer kein Französisch lesen kann, kann die Seiten ja im "Playboy-Modus" (nur die Bilder anschauen) durchscrollen. :)


    Bei "bewegter Grafik" rutschte der CPC dann schon allein aufgrund fehlender Sprites und Scrolling schnell nach unten. ;)

  • Vielleicht kann M. J. was dazu schreiben.

    8| Wieso ausgerechnet ich?

    Keine weiteren Einschränkungen (je Zeile, Block oder irgendwas)?

    Die Einschränkung lautet, daß eine normale Bitmap ~16 kb umfaßt, also doppelt so viel wie beim C64. Um Flackern aufgrund des Zeichnens und Löschens von Softwaresprites (Shapes) zu vermeiden, greift man gerne auf DoubleBuffering zurück, was dann mal eben insgesamt ~32 kb kostet. Anders als beim C64 läßt sich die Bitmapadresse auch nicht per Rasterinterrupt während des Bildaufbaus umschalten, so daß man die Bitmap nicht aufspalten kann in einen Aktionsbereich (mit DoubleBuffering) und einen relativ festen Teil (Scoreanzeige), um Speicherplatz zu sparen. Das ist nur dann möglich, wenn man auf ein vollständiges DoubleBuffering verzichtet und die Grafik zunächst in eine virtuelle Bitmap zeichnet, die am Ende in die Anzeigebitmap kopiert wird. (Hierfür hat der Z80 allerdings einen schnellen Kopierbefehl).

    Jetzt die nächste (wahrscheinlich ernüchternde) Frage: Wieviel Software-Sprites (sagen wir mal in 24x24 oder 16x16 Pixeln Auflösung) (oder wieviele Pixel insgesamt) könnte man denn in einem Spiel mit 50/60 fps realistischerweise (natürlich in Assembler) über den Bildschirm bewegen?

    Diese Frage läßt sich pauschal nicht beantworten. da die Antwort von zu vielen verschiedenen Faktoren abhängt.

    1.) Wie oben erwähnt: Benutzt das Programm DoubleBuffering (aufwendig)? Oder einen virtuellen Grafikpuffer (aufwendig und langsam)?

    2.) Gibt es einen Hintergrund, der beim Löschen des Shapes restauriert werden muß? Besteht der Hintergrund nur aus einer Farbe (z. B. Weltraumschwarz), ist das Löschen wesentlich einfacher, als wenn man entweder durch Kopieren des Hintergrunds in einen Puffer oder durch Neuzeichnen auf der Basis von Kacheln den Hintergrund wiederherstellen muß.

    3.) Benötig man eine zusätzliche Maske, um das Shape in den Hintergrund reinzustanzen?

    4.) Werden die Figuren pixelweise bewegt oder orientieren sie sich an Bytegrenzen?

    5.) Bei einer pixelweisen Bewegung: Werden die Shapes in verschiedenen Positionen im Speicher abgelegt, so daß man für jeden X-Wert sofort das korrekte Sprite hat, oder werden die Shapes (z. B. anhand einer Tabelle) in Echtzeit verschoben, um Speicherplatz zu sparen?

    6.) In geschickten Händen kann der Z80 schneller sein als ein 6502, und obgleich der Speicherverbrauch der Bitmaps recht hoch ist, läßt sich dies durch die höhere Codedichte des Z80 zumindest ein wenig ausgleichen, zumal der CPC anders als der C64 ein schnelles Laufwerk hat zum Nachladen.


    Generell gilt auch, daß bei einem DoubleBuffering eine Framerate von 25 für viele Arcadespiele bereits ausreicht, sofern halt nicht zu große Objekte bewegt werden, so daß ich persönlich keine echte Notwendigkeit für 50/60fps sehe. Ist halt die Frage, was genau man unter Arcade versteht. Wenn es so wie bei den Spielautomaten aussehen soll (mit 60fps), wird es schwierig (wenn auch nicht unmöglich), aber ansonsten lassen sich Actionspiele durchaus auch auf dem CPC gut spielen. (Gab es ja auch auf dem AppleII, und der hatte ebenfalls keine Sprites oder einen Zeichensatzmodus.) Ein Spiel wie Euer "Bomb Jack" sollte also machbar sein, wobei man da wirklich austesten müßte, ob es z. B. gelingen könnte, die Figuren während der vertikalen Austastlücke zu malen, um so auf das speicherintensive DoubleBuffering zu verzichten. Eine Abschätzung dafür kann ich aber nicht geben, da mir - anders als es oobdoo suggeriert - für sowas die Erfahrungswerte fehlen.

  • 8| Wieso ausgerechnet ich?

    Ich musste viel Knowhow-Text von Dir löschen. ;)


    Während ich viel dummes Zeug schreibe und

    möglicherweise deswegen in ein oder zwei Filtern

    stecke, ist von Dir immer geballte Kompetenz zu lesen. :thumbsup:

  • Pinball Dreams scrollt vertikal, was an sich schon andere Spiele als Softscrolling hinbekommen haben (wenn auch nicht in der Framerate). Das Spiel halte ich auch für die Referenz auf dem CPC, wenngleich man berücksichtigen muss, dass die Grafik nicht über die gesamte Bildbreite reicht und die Kugel als einzelnes Objekt bewegt wird.

  • Die Einschränkung lautet, daß eine normale Bitmap ~16 kb umfaßt, also doppelt so viel wie beim C64. Um Flackern aufgrund des Zeichnens und Löschens von Softwaresprites (Shapes) zu vermeiden, greift man gerne auf DoubleBuffering zurück, was dann mal eben insgesamt ~32 kb kostet.

    OK, 32KB Grafikpuffer bei einem 64KB-Rechner sind natürlich schon eine "Einschränkung". Die Frage ist, ob man nicht gleich auf die 128 KB eines CPC 6128 setzen sollte/könnte. Konnten die 64KB-CPCs auf 128 KB aufgerüstet werden? – und wurde das vielfach getan (und von Games unterstützt)? Das würde den erhöhten Bitmap-Speicherbedarf ausgleichen.


    1.) Wie oben erwähnt: Benutzt das Programm DoubleBuffering (aufwendig)?

    Sowas müsste man natürlich klären – aber wenn das Malen in der vertikalen Austastlücke möglich wäre, wäre das natürlich zu favorisieren.


    2.) Gibt es einen Hintergrund, der beim Löschen des Shapes restauriert werden muß? Besteht der Hintergrund nur aus einer Farbe (z. B. Weltraumschwarz), ist das Löschen wesentlich einfacher, als wenn man entweder durch Kopieren des Hintergrunds in einen Puffer oder durch Neuzeichnen auf der Basis von Kacheln den Hintergrund wiederherstellen muß.

    Logisch, dass es einfacher ist, Shapes auf einheitlichen Flächen (z.B. schwarz) zu bewegen, weil man die nicht beim Umpositionieren "retten" muss. Nicht umsonst sind viele Spiele für Rechner ohne Hardware-Sprites so aufgebaut. Ich würde aber grundsätzlich erstmal davon ausgehen, dass wir hier über Spiele sprechen, die durchaus den Hintergrund retten und restaurieren müssen. Sonst wäre es ja zu einfach. ;)


    3.) Benötig man eine zusätzliche Maske, um das Shape in den Hintergrund reinzustanzen?

    Du meinst, ob das Shape einen "Shape" hat, also nicht einfach rechteckig ist? ;) Ja, davon ist auszugehen. Oder ist die Frage, ob die Ausstanzung von der durch die Pixel gesetzten Form abweicht?


    4.) Werden die Figuren pixelweise bewegt oder orientieren sie sich an Bytegrenzen?

    Ich gehe hier von Bewegungen feiner als charweise aus. Solche Sprünge fände ich doch etwas zu grob. Notfalls ginge das aber für bestimmte Objekt, wie Schüsse (da kennt man das ja beim C64 auch). Aber die großen Figuren sollten sich schon "frei" bewegen können.


    5.) Bei einer pixelweisen Bewegung: Werden die Shapes in verschiedenen Positionen im Speicher abgelegt, so daß man für jeden X-Wert sofort das korrekte Sprite hat, oder werden die Shapes (z. B. anhand einer Tabelle) in Echtzeit verschoben, um Speicherplatz zu sparen?

    Ich gehe von letztrem aus. Aber danke für den Tipp – ab und zu kann man sowas ja durchaus verwenden.


    zumal der CPC anders als der C64 ein schnelles Laufwerk hat zum Nachladen.

    Apropos Laufwerk: Weiß jemand, ob das zum Grafik-Nachladen beim Bomb Jack-Port verwendet wurde? Da sind ja 5 große Backdrops drin und mit crunchen war man damals (außerhalb der Cracker) ja nicht so sehr vertraut.


    Generell gilt auch, daß bei einem DoubleBuffering eine Framerate von 25 für viele Arcadespiele bereits ausreicht

    OK, das kann man natürlich nutzen.


    Ein Spiel wie Euer "Bomb Jack" sollte also machbar sein, wobei man da wirklich austesten müßte, ob es z. B. gelingen könnte, die Figuren während der vertikalen Austastlücke zu malen, um so auf das speicherintensive DoubleBuffering zu verzichten.

    Was die Machbarkeit angeht, habe ich momentan zwar sowas wie Bomb Jack im Hinterkopf (aber nur von den grafischen Vorgaben her) – ich gehe aber von keinem weiteren Port aus – die CPC-Version wird ja auch von den CPC-Fans gefeiert, da würde ich gar nicht reingrätschen wollen (obwohl ich auch da deutliches Verbesserungspotentiel sehe).


    Es stellt sich also die Frage, ob man auf einem abwechslungsreichen (nichtscrollenden) Mode-0-Bitmapscreen z.B. 8 Shapes (ungefähr in C64-Sprite-Größe) pixelweise (in 25 fps) über den Bildschirm bewegen kann (und noch genügend Rechenleistung für Game-Logik, Musik usw. übrig hat). Es geht um Games, nicht um hochoptimierte Demos. Ist sowas denkbar (oder schon gemacht worden)? Wo sind die Grenzen?

  • Der Sprite-bezogene Teil nochmal anders formuliert: Kann man auf dem CPC per Software eine Sprite-Engine, ähnlich der C64 Hardware-Lösung, hinbekommen? Unter den vereinfachenden Voraussetzungen, dass man nicht gleichzeitig scrollen möchte und mit 25 fps für die Shape-Aktualisierungen zufrieden wäre? (Immerhin sprechen wir von einem 4 MHz-Rechner.)

  • Retrofan
    Also, sowas wie eine software-basierte Allrounder-Sprite-Engine in 25fps kann ich mir beim CPC nicht so wirklich vorstellen. Bzw man sieht an den Referenzspielen auf dem System, dass man schon Einiges machen kann, allerdings gibt es bei jedem Spiel bei näherem Hinsehen auch deutliche Kompromisse und das wird recht sicher auf die jeweiligen Spiele zugeschnitten sein. Bei der Grafikbasis relativieren sich auch 4Mhz schnell.


    Allerdings... der CPC+ geht an sich schon in die Richtung, die du dir vorstellst. Das System bekam zusätzlich Sprites, Softscrolling, eine erweiterte Farbpalette...