Hallo Besucher, der Thread wurde 3,6k mal aufgerufen und enthält 17 Antworten

letzter Beitrag von Retrofan am

Wie entstehen Grafiken für Spiele und Demos am C64?

    Hallo,


    ich ackere mich gerade durch das Buch "C64 - Wunderland der Grafik" und bin nun theoretisch in der Lage, mit vergleichsweiswe viel Kopfrechnen eine Bitplane zu setzen und diese im Grafik-Modus zu verändern - alles per OR-Verknüpfungen und Koordinaten-Ausrechnen-Aufwand.


    Wie machen, bzw. machten das denn richtige Grafiker? Die Levelgrafiken zu Katakis oder Giana Sisters können doch so nicht entstanden sein?


    Ich kenne es vom Amiga, dass man DPaint genommen hat, eine IFF-Grafik damit erstellt hat und der Programmierer konnte mit dieser Grafik dann arbeiten, bzw. sie einlesen, darstellen, was auch immer.


    Wie werden am C64 Grafiken erstellt und gespeichert? Doch nicht etwa als Programme die lauter Befehle zum Setzen von Punkten enthalten?

    Die Grafiken in Spielen (wie zum Beispiel das erwähnte Katakis und Giana Sisters) werden auch nicht im Grafikmodus erzeugt, sondern im Multicolor Textmodus. Der Zeichensatz wird modifiziert und die Levelgrafiken aus dem Zeichensatzelementen zusammengebastelt. Diese Elemente werden von Hand mit einem entsprechenden Tool gepixelt.

    Hier sind einige Infos zu den verschiedenen Formaten: http://www.editorix.org/congo/…mage_formats__part_i.html


    Bei Spielen werden eher Multicolor-Charsets verwendet, die sich dann schnell scrollen lassen. Dazu gibt es heute schon schöne Editoren.

    Das heißt, so ein Editor ist ein Tool, mit dem man die Levelgrafik bastelt und dann sagen kann: So, das ist mein Level. Speichere das als Datei.
    Und im Programmcode des Spiels geht man her und sagt: Du Datei, Dich kopiere ich ins RAM und die Bitmap wo das Spielgeschehen gerade ist, stellt den gerade aktuellen Ausschnitt dar?

    Zitat von Bytebreaker

    Das heißt, so ein Editor ist ein Tool, mit dem man die Levelgrafik bastelt und dann sagen kann: So, das ist mein Level. Speichere das als Datei.
    Und im Programmcode des Spiels geht man her und sagt: Du Datei, Dich kopiere ich ins RAM und die Bitmap wo das Spielgeschehen gerade ist, stellt den gerade aktuellen Ausschnitt dar?


    Jaein. :) Hier hatte ich mal herum gespielt: Mal wieder Scrolling ... . Diese ganze VIC-Programmierung ist auch nicht so mein Ding, aber vielleicht kannst Du damit etwas machen. Da sollte das Prinzip schon deutlich werden.
    Die Charsets und Level-Screens kann man natürlich besser in einem Editor erstellen.


    edit: hier wirst Du viele Antworten finden: Project J - Wir schreiben ein C64 Spiel in mehreren Schritten

    Wie schon erwähnt wenden die meisten Spiele einen modifizierten Zeichensatz für die Darstellung an, also ist das ganze eine Tilemap (englisch: Tile -> Kachel, also eine Karte aus kleinen Kacheln)


    Das Spiel selbst lädt also den modifizierten Zeichensatz und setzt die Register des VIC passend damit dieser Zeichensatz statt des originalen aus dem ROM verwendet wird.
    Dann lädt das Spiel noch eine Karte ein, die im Prinzip aus nichts mehr als den Zeichencodes der verwendeten Zeichen besteht. Bei einem feststehenden Bild was so groß ist wie der Bildschirminhalt wären das 1000 Bytes - 40*25 Zeichen. Die können dann auch direkt in das ScreenRAM geladen werden. Wenn es sich um seinen Scroller handelt wird die Karte an anderer Stelle vorgeladen und stückweise ins ScreenRAM kopiert.
    Wenn Du zB einen Level hast der zwei Bildschirme breit ist werden also 2000 Byte eingeladen. (80*25 Zeichen).
    Die Position die in das Screenram kopiert wird ist dann per simpler Mathe herauszufinden:


    Speicheradresse des Zeichens = Startadresse im Speicher+(start_des_auschnittes_x+x-Position+((start_des_ausschnittes_y+y-position)*Kartenbreite))


    Dein Spiel verschiebt also (in obigem Beispiel) nur die Startposition des Ausschnittes von 0-40 und setzt diese in die Formel ein, der Start des y-Ausschnittes ist immer bei 0, da ja nicht hoch und runter gescrollt wird.
    Die Formel oben wird dann für alle Positionen des Bildschirmes in einer verschachtelten Schleife aufgerufen, also x-position von 0-39 und y-position von 0-24, damit alle Zeichen des aktuellen Ausschnittes kopiert werden.


    Einkopiert wird das ermittelte zeichen ebenso:
    Position am Screen = start des Screens (bei frisch eingeschaltetem C64:1024) + x-position+(y-position*40) ;vierzig, weil der Screen des C64 ja 40 Zeichen breit ist.


    Nun hast Du dann ein erstes Scrolling, welches aber sehr rucken wird, da immer um komplette Zeichen verschoben wird. Um feieneres Scrolling zu ermöglichen musst Du dich dann noch mit den Scroll-Registern des VIC beschäftigen, da hiermit pixelweise verschoben werden kann und erst alle 8 verschiebungen ein kopieren der Zeichen erfolgen muss.

    Zitat von Squidward

    Einfach mal was mit Charpad malen, so versteht man die "Machart" (im Sinne von Aufbau) ganz gut... :)


    Ja, Charpad ist zum lernen, wie der Graphikaufbau (Chars, Tiles und Map) ist schon sehr gut!


    Leider kann man damit aktuell nur Tiles in einer Größe (2x2 Chars, 3x3 Chars usw.) verwalten.
    Das soll übrigens in der nächsten Version geändert werden.
    "The good news is that there is a new version in the pipeline that offers more variety with tile sizes, it will allow the tile width and height to be independently altered (up to 5x5) so you can for example have a tile size of 4x3 or 3x2 or 5x1 or whatever."


    Alternativ setze ich große Hoffnungen in zukünftige Versionen von VChar (https://github.com/ricardoquesada/vchar64)...

    Die Grafiken für meine ersten Intros habe ich mit 0xpaint gemalt, das allerdings einige Bugs hat, aber sehr einfach zu bedienen ist.
    Beliebt ist auch Project One, da es sehr umfangreich ist.
    Und für etwas derbere Grafikformate dann Timanthes, das allerdings dann nicht mehr so leicht zu bedienen ist.
    Die Tools CharPad und SpritePad von Subchrist Software empfehlen sich, wenn man Spielegrafiken entwirft.


    Das einfachste Speicherformat ist sicher das Koala-Format. Entweder unterstützt euer Grafikprogramm den Format dieses Formates oder ihr müsst das über einen Umweg mit einem Retro Replay Cartridge machen, das einen Koala Ripper anbietet.

    Zitat von BladeRunner

    Wenn Du zB einen Level hast der zwei Bildschirme breit ist werden also 2000 Byte eingeladen. (80*25 Zeichen).


    Wobei man dazu vielleicht erwähnen könnte, dass diese Tiles oft wiederrum zu grösseren Elementen zusammengefügt werden um Speicherplatz für die Screenmaps zu sparen. Dann besteht vielleicht ein Bildschirm nur noch aus 12 Elementen, da lässt sich dann einiges an Levelmaps unterbringen..

    Zitat von Ace von Heisenberg

    Du willst doch nur wieder Skandale :P


    Nein, lernen!
    Mir ist das mit der Grafik am 64er nämlich immer noch nicht klar. Aber der Sache werde ich auf den Grund gehen, wenn mein aktuelles Projekt mal funktioniert.

    Zitat von Ace von Heisenberg

    Frag mal Retrofan. Der hatte hier vor Jahren mal einen interessanten Thread dazu gemacht und das sehr ausführlich erläutert.


    Wenn es soweit ist, dann such ich das mal raus.

    Spiele existieren in allen sinnvollen Grafikformaten, die der C64 zur Verfügung stellt – aber die meisten werden wohl im Multicolor-Char-Modus gebaut worden sein. Der Vorteil des Char(acter)-Modus: Die "Grafik" liegt platzsparend als veränderter Zeichensatz vor, aus dem dann das "Bild" zusammengebaut wird.


    Fast alle Spiele, die scrollen, nutzen Char-Grafik. Leider hat Commodore nicht daran gedacht, einen reinen Multicolor-(Char)-Modus anzubieten. Damit man Text und Bild mischen kann, kann dieser Modus gemischt Multicolor (halbe Auflösung, mehr Farben) und Hires (volle Auflösung, nur eine wählbare Farbe zusätzlich zum festen Background) darstellen. Man erkauft sich die Auflösungs-Flexibilität allerdings mit einer geringeren Farbauswahl in den Multicolor-Chars.


    Hires-Modi (egal ob als Chars oder als Bitmap-Modus) werden eher selten für C64 Spiele verwendet. Man kann nur 2 Farben je Char (8x8 Pixel) verwenden (im Char-Mode steht sogar eine der Farben für den ganzen Screen fest) und man kann trotzdem nicht mit den einzelnen Pixeln komplett frei verfahren, weil die alten Röhrenmonitore durch ihre geringe Schärfe auch noch ein Wörtchen mitreden (horizontale, feine Linien sind z.B. problematisch). Unbeliebt ist der Hires-Char-Modus aber meines Erachtens vor allem, weil Spiele, die diesen Modus nutzen, fast immer ZX-Xpectrum-artig aussehen (denn dieser Rechner kannte ausschließlich Hires-Grafik mit 2 Farben je Char) und man will/wollte sich ja immer von den Konkurrenten (vor allem den "schwächeren") absetzen.


    Extrem selten kommt der ECM-Modus in Spielen vor: Nur noch 64 (statt 256) Hires-Chars, dafür 4 Hintergrundfarben zur Auswahl (statt nur einer).


    Der Multicolor-Bitmap ("Koala") Modus wird auch nicht sehr oft für Spiele verwendet. Man hat hier die geringsten Farbeinschränkungen, kann aber nicht (wie beim Char-Modus) mit Hires mischen. Da man deutlich mehr Bits bewegen muss, wenn man scrollen will, fällt dieser Modus auch weitgehend für Spiele mit Scrolling aus. Auch typische Parallax-Effekte kann man nicht nutzen, da sich Grafik nicht einfach dadurch verändert, dass man Chars modifiziert (ein Trick bei Parallax-Effekten). Erst durch manuellen Neuzeichnen sähe man den veränderte Char. Weil man wegen des geringen Pixel-Durchsatzes sehen würde, wie Elemente auf den Screen gemalt werden, bedient man sich bei diesem Modus am Besten des sog. "Doublebufferings". Man "malt" immer in einem unsichtbaren Duplikat des Screens und schaltet dann diesen schnell sichtbar. Das kostet allerdings Speicher, weil man ja 2 Screens verwaltet.


    Baut man größere Levels (deutlich größer als der Screen) aus Chars zusammen (für Scrolling-Games), ist es meistens so, dass man einen Zwischenschritt über "Tiles" geht. Man baut also aus Chars größere Gruppen (das sind die Tiles) zusammen und baut den Level dann aus den Tiles. Das spart Speicher bei der Verwaltung des Levels.


    Wir (P1X3L.NET) haben bisher an 4 RGCD-16K-Game-Wettbewerben teilgenommen. Zwei unserer Spiele haben wir in Multicolor-Bitmap-Grafik gebaut, ein Spiel nutzt Multicolor-Char-Grafik und ein Spiel nutzt Hires-Char-Grafik.


    Man sollte sich am Besten frühzeitig für den geeignetsten Grafik-Modus entscheiden, dann kann man so einiges darauf hin optimieren.


    Ich erstelle alle Grafikelemente in einem stinknormalen Grafikprogramm (ich verwende Photoshop, es ginge aber auch GIMP oder irgendwas anderes). Da ich die Farb-Einschränkungen des C64 kenne, kann es höchstens aus Unachtsamkeit vorkommen, dass ich über das Ziel hinausschieße. ALeX, der Programmierer im Team, hat selbstgeschriebene Grafik-Konverter am Start, die meine Grafiken (sie liegen immer im PNG-Format vor) in Chars oder Sprites umwandeln und sie ins Projekt einfügen.


    Ein informativer Link zum Thema.