Hallo Besucher, der Thread wurde 242k mal aufgerufen und enthält 1853 Antworten

letzter Beitrag von Retrofan am

Neuer Retro-Computer im 8-Bit Style

  • Hmm... Den AtariST kenne ich nicht gut genug, aber beim Amiga hat der Blitter nicht gerade Wunder gewirkt. Ich hatte an anderer Stelle schon darauf hingewiesen, daß von den mir bekannten 3d-Spielen nur "F18 Interceptor" und "Interphase" den Blitter zum Füllen von Flächen einsetzen. "Carrier Command" und verwandte Spiele der gleichen Engine benutzen den Blitter zum Malen von LInien, horizontalen Flächenlinien und Rechtecken. DIe wirklich schnellen 3d-Spiele wie "No Second Prize" oder "Virus" verwenden den Prozessor nur zum Löschen des Hintergrunds und stützen sich ansonsten auf den Prozessor. Nachteil des Blitters: Auch das Setzen der Blitterregister kostet viel Zeit.

    Für mich war der Blitter damals der Grund warum viele Spiele so nicht auf dem Atari ST möglich waren. Mal vom Linien zeichnen und Flächen füllen abgesehen, konnte man ja mit Setzen von ein paar Registern schön schnell Ram-Blöcke verschieben, mit Maske etc. Klar hat das die CPU auch aus gebremst, aber unterm Strich konnte man, meiner Meinung nach, mit einer 8MHZ 68000 CPU das nicht so schnell hinbekommen wie mit dem Blitter. Aber wirkliche Interna kenne ich nicht, da bist du der Experte. Der 68000er war die erste CPU mit der ich mich in Assembler damals probiert hatte. Aber ich habe auch nie getestet wie schnell es wäre Blockkopien mit Verknüpfung von mehreren Quelle nur mit der CPU Pixel für Pixel zu kopieren. Früher war so das Gerücht, dass der Blitter das so schnell hinbekommt wie eine 20Mhz CPU. Deswegen machte es wohl bei höher getakteten CPUs keine Sinn mehr den Blitter einzusetzen, bei 8Mhz aber sehr wohl.

  • Es arbeitet mit Bitmaps, allerdings hab ich mir für meine Spiele ein Spritesystem selber erstellt

    Ich nehme an, die "Sprites" beruhen im Grunde genommen auf Shapes, oder? Dann wirst Du entweder die Methode verwendet haben wie beschrieben oder Du hast jeweils den Bildschirmhintergrund unter dem Sprite in einem Puffer gerettet und beim Löschen der Figur daraus restauriert. Welchen Weg auch immer Du verwendet hast, führt es ja am Ende dazu, daß ein Sprite auf einem Shape basiert. Wenn Du also so gut mit BlitzBasic und dem Bitmap-Prinzip klar gekommen bist, dürfte es Dir und vielleicht auch anderen kein Problem bereiten, auf gleiche Weise auf einem Retrorechner zu arbeiten. Ich würde sogar sagen, Du wärest damit ein idealer Programmierer für ein erstes Demospiel. ;)

    Blitz Basic für Windows arbeitet mit Front- und Backbuffer. Das heisst, man zeichnet das fertige Bild in den Backbuffer und wechselt dann mit dem Befehl FLIP den Buffer.


    Also:

    Finde ich eine sehr gute Lösung, allerdings müßte das kopieren vom Back- in den Frontbuffer sehr, sehr schnell funktionieren, damit eine flüssige Animation erzeugt werden kann. Im übrigen benutzt Blitz Basic das Funktionsprinzip!

  • Hmm also ich halte das Prinzip mit Chars/Tiles in einem Screen Buffer schon fuer "oldschooliger" und irgendwie spezifischer. Klar, heutzutage macht man eigentlich alles so mit Front- und Backbuffer und man zeichnet halt einfach sein Bild da rein und zeigt dies dann an. Aber die Sache mit einem Char Buffer oder Tile Buffer hat halt schon auch was fuer sich. Ist schwer zu entscheiden was man da jetzt nehmen sollte - die oldschool-Loesung um mehr "Retro" zu sein (hat auch gewisse Vorteile, z.B. hat man permanent ein "Bild" im RAM welches sich aendern laesst, aber auch abfragen laesst, z.B. welches Char oder Tile befindet sich gerade auf dem Bildschirm an Stelle XY), oder die moderne Loesung mit zwei Bitmap-Buffern (welche dann den Vorteil haette, dass man lernt wie man es heute macht, aber die Frage ist halt wiederum ob das zum Retro-Konzept passt).

  • Dabei ist Char/Tile ja fast schon modern. Nintendo hat das ja hardwaregestuetzt sehr weit getrieben. Schon beim VirtualBoy und dann entsprechend ausgefeilter beim GBA etc.

    Atari Lynx zB setzte zuvor komplett auf Bitmap mode mit einem schnellen 'Blitter' der quasi die Sprites in Software setzt.

  • Dabei ist Char/Tile ja fast schon modern.

    Die Aussage würde ich definitiv nicht unterschreiben, Videochips mit Tile-Grafik gabs schon vor dem NES. Der VIC-I des VC20 war ja auch ursprünglich für Arcade-Spiele gedacht und Textmodus ist nichts anderes als Tile-Grafik.



    Nintendo hat das ja hardwaregestuetzt sehr weit getrieben. Schon beim VirtualBoy und dann entsprechend ausgefeilter beim GBA etc.

    Du hast dir noch nie das NES oder SNES näher angeschaut, oder?



    Atari Lynx zB setzte zuvor komplett auf Bitmap mode mit einem schnellen 'Blitter' der quasi die Sprites in Software setzt.

    Ach deswegen war der so ein Batteriefresser ;)

  • Viele Arcade-Kisten haben doch auch einen Char-Modus, oder nicht? Bestes Beispiel duerfte ja das 256. Level von Pacman sein. Oder bei der Boot-up-Sequenz, da sieht man ja oft auch wie der gesamte Bildschirm mit Chars gefuellt wird etc...

  • Huhu ... bin neu hier

    a) 384 x 216 @ 4 (und daraus ergebend: 192 x 216 @ 16 und 768 x 216 @ 2). Die Auflösungen ergeben sich aus der Full-HD-Auflösung von 1920 x 1080 Pixeln (HD/5 beim mittleren Modus).

    Bei 768 x 216 hat man aber keinen ganzzahligen Teiler mehr oder ? 1920 / 768 = 2,5

    Dann wäre ja ein Pixel 3 und der nächste 2 Bildschirm-Pixel breit. usw. usf.



    Eine runtergesetzte Auflösung bei 1080p würde ja auch Sub-Pixel-Scrolling ermöglichen. Man kann die grossen Computer-Pixel ja Bildschirm-Pixel weise verschieben.


    Ich würde ja ein plumpes /4 nehmen. Ergibt 480x270.

    Wenn man den internen Bildschirm-Buffer auf 512x256 festnagelt, dann könnte man wahrscheinlich recht leicht ein "Modulo-Buffering" realisiern. Sprich: Grafik die links rausgeschoben wird, wird automatisch rechts wieder eingeblendet. Zum "Nachfüllen" bietet der Buffer horizontal genug Platz nur für vertikales Scrolling müsste man ggf. die Bildschirm-Darstellung beschneiden auf vielleicht 480x240.


    Ansonsten hab ich mich beim Amiga immer gefragt warum es keinen "Hold"-Mode gibt. Also HAM nur mit ohne modify. In diesem Modus wäre eine Farbe, nehmen wir einfach die letzte der Palette die Halte-Farbe. Wird diese Farbe aus dem Video-RAM geladen wird einfach die zuvor ausgegebene Farbe wiederholt. Damit verliert man zwar eine Farbe aber bekommt Füllrate gratis, da immer nur ein Punkt gesetzt werden muss wenn sich die Farbe ändert (sofern das Video-RAM vorher mit der Füll-Farbe gefüllt wurde).


    Kurzes Beispiel:

    Video-RAM mit Füll-Farbe gefüllt -> man sieht die Hintergrund-Farbe

    Man setzt oben links den ersten Pixel auf gelb -> erste Zeile wird gelb.

    Man setzt in der zweiten Zeile einen Pixel in der Mitte auf grün -> erste Zeile gelb, zweite Zeile erst Hintergrund-Farbe dann grün.


    Das wäre ggf. was für gefüllte Vektor-Grafik auf einem CPU schwachen System.



    Ansonsten

    ist schön hier bei euch

  • Das wäre ggf. was für gefüllte Vektor-Grafik auf einem CPU schwachen System.

    Stell Dir vor, Du erzeugst ein grünes Rechteck, welches 10 Pixel breit und 5 Pixel vom linken Rand entfernt ist. Die Hintergrundfarbe ist rot. Dann gilt:

    RrrrrGgggggggggRrrrrr....

    R = Rot wird gesetzt, r = rot wird gehalten, G = Grün wird gesetzt, g = grün wird gehalten

    Wenn man jetzt ein blaues Rechteck der Breite 4 mittig über das grüne Rechteck legt, so daß sowohl links als auch rechts ein grüner Rand entsteht, sieht das so aus:

    RrrrrGggBbbbGggRrrrrr....

    Jetzt das Problem: Woher weiß die Malroutine, daß am rechten Rand des blauen Rechtecks die Farbe wieder auf Grün gesetzt werden soll?


    Hinweis am Rande: Wenn man sich mal Anzeigen von 3d-Spielen anguckt, stellt man fest, daß die meisten Polygone in ihrer horizontalen Breite bezogen auf eine Y-Zeile eher schmal sind (deutlichstes Beispiel: "Virus" oder "Zeewolf"). Wirklich breite Polygone entstehen nur dann, wenn sich Objekte sehr nah an der Kamera (dem Spieler) befinden, was jedoch nicht der Normalfall ist. Nun läßt sich beim Amiga und noch mehr beim AtariST eine kurze horizontale Linie sehr schnell mit dem Prozessor malen, schneller sogar, als wenn man dafür extra den Blitter anschmeißen würde. Bei Deinem System müßte man hingegen pro Zeile so eine Art Liste bereitstellen, die festhält, von welcher X-Koordinate an eine bestimmte Farbe gesetzt wurde. Daraufhin würde das Programm diese Liste durchsuchen, seinen linken X-Wert eintragen und alle X-Koordinaten, die sich zwischen dem linken und rechten Rand befinden, löschen und die zuletzt genannte Farbe zur Bestimmung des neuen rechten Randes nehmen. Dieses Verfahren ist denkbar, aber es dürfte viel mehr Zeit kosten, als eine (kurze) horizontale Linie direkt in die Bitmap zu plotten.

  • Zwar Offtopic, aber was ich beim Amiga echt mies fand an der Grafikprogrammierung waren diese Bitplanes, um ein Pixel zu setzen musste man bis zu fünf Bytes anfassen wenn man im 32 Farben Modus war. Auf dem PC hat man in VGA ein Byte setzen müssen und hatte 256 Farben. Das war beim Amiga echte Verschwendung von Rechenzeit. Beim ST weiß ich es jetzt gar nicht, ob der auch diesen Bitplane Mist hatte.

  • Bei 768 x 216 hat man aber keinen ganzzahligen Teiler mehr oder ? 1920 / 768 = 2,5

    Dann wäre ja ein Pixel 3 und der nächste 2 Bildschirm-Pixel breit. usw. usf.

    [..]

    Ich würde ja ein plumpes /4 nehmen. Ergibt 480x270.

    Ja, da hast Du recht. Die tatsächlich naheliegendste Auflösung wäre 480x270. Leider verträgt sich diese gar nicht gut mit den alten VGA-Bildschirmen, die z. B. ich hier zum Austesten verwende. Dann hätte man auf einem eh schon kleinen VGA-Bildschirm (15") einen Rand von 80 links und 80 rechts. Da die vertikale Auflösung 480 beträgt, ergibt die Hälfte für eine Zeilenverdopplung nur 240, was nicht ausreicht. Man müßte also die vertikalen 270 direkt auf die 480 mappen, so daß es oben und unten einen Rand gibt von jeweils 105. Insgesamt hat man dann ein arg kleines und in der Breite verzerrtes Bild. ;( Prinzipiell sind Deine Angaben also völlig richtig, aber in der Praxis erweisen sie sich leider als unhandlich.

    Finde ich eine sehr gute Lösung, allerdings müßte das kopieren vom Back- in den Frontbuffer sehr, sehr schnell funktionieren, damit eine flüssige Animation erzeugt werden kann.

    Genauso programmiere ich auf dem PC auch, wobei es dann noch den Unterschied gibt, ob man direkt auf der Grafikkarte rendern läßt oder im Arbeitsspeicher malt und das Ergebnis auf die Grafikkarte kopiert. Ein Kopieren innerhalb des Rams der Grafikkarte ist jedenfalls sehr schnell. Da bräuchte man sich keine Sorgen zu machen.

    Bei einem Retrorechner läuft es fast gleich ab mit dem Unterschied, daß die Daten nicht vom Back- in den Frontpuffer kopiert werden müssen, sondern einfach Front- und Backpuffer vertauscht werden. Das ist dann nochmals schneller, von der Methode her aber ziemlich identisch.

    Für mich war der Blitter damals der Grund warum viele Spiele so nicht auf dem Atari ST möglich waren.

    Ich bin jetzt auch nicht der große Amiga-Spielprogrammierer-Experte, aber ich könnte mir vorstellen, daß es weniger am Blitter lag als daran, daß der AtariST kein Hardwarescrolling (in X-Richtung) kannte. Spiele wie "Goldrunner" oder "Paradroid90" hatten kein Problem, die Grafik vertikal zu scrollen, da man hierbei ganze Speicherwörter direkt kopieren kann. Ein pixelweises Verschieben nach links oder rechts braucht jedoch aufwendige Routinen, und da der alte 68000 noch keinen Barrel shifter hatte, benötigte jedes Verschieben um ein Pixel 2 Takte. Bei Shapes ist das kein großes Problem, da man diese vor Spielbeginn in einen Verschiebecache packen kann, welcher alle 16 möglichen Positionen enthält. Bei Hintergrundgraphik wird es aber schwierig.

    Hmm also ich halte das Prinzip mit Chars/Tiles in einem Screen Buffer schon fuer "oldschooliger" und irgendwie spezifischer.

    Für jemanden, der sich hauptsächlich mit dem C64 beschäftigt, ist das auch völlig normal. Ich möchte aber trotzdem daran erinnern, daß von den drei weiteren großen Platzhirschen der Homecomputer-Ära, als da sind AppleII, CPC und Sinclair ZX Spectrum, keiner über eine Zeichensatzgraphik verfügt und folglich Spiele mit Grafik stets auf Bitmap basieren. Beim C64 ist es leider so, daß viele C64-Programmierer erst nach vielen Jahren(!) entdeckt haben, daß der C64 auch über Bitmap verfügt. Spiele wie "Defender of the Crown" hätte man auch schon viel früher haben können.

    Hier mal eine unvollständige Liste von C64-Spielen, die nicht Zeichensatzgrafik für ihre Grafik verwenden:

    Amazon, Accolade Comics, Bandits, Borrowed Time, Conan, Cybernoid, Defender of the Crown, Dragon Wars, Drol, Elite, Gremlins, Gunship, Hard Hat Mack, Jinxter, Karateka, Koronis Rift, Law of the West, Mercenary, Monster Buster, Prince of Persia, Psi5 Trading Company, Rescue on Fractalus, Space Rogue, Spellbound, Stifflip, Test Drive I+II, The Bard's Tale I-III, The Eidolon, The Goonies, The Last Ninja I-III, Ultima IV-VI, Wasteland, Wavy Navy, Where in the World is Carmen San Diego, Wings of Fury.

    Nintendo [..] Atari Lynx

    Arcade-Kisten

    Arcade-Kisten

    Vielleicht wäre es sinnvoll, sich darauf zu einigen, worum es gehen soll: Retro-Rechner oder Retro-Spielkonsole?

  • Beim ST weiß ich es jetzt gar nicht, ob der auch diesen Bitplane Mist hatte.

    Ja, wenn auch anders angeordnet. Beim Amiga lagen die Bitplanes bei einer 320x200x16-Grafik je nach Mod-Einstellung entweder 8000 oder 40 Bytes auseinander. Um einen einzelnen Punkt zu setzen, war das recht aufwendig. Bei einer horizontalen Linie hingegen (sprich: Polygon) fiel dies weniger ins Gewicht, da sich dadurch die Anzahl der Bytes, die man insgesamt setzen mußte, nicht viel änderte.

    Beim AtariST waren die Planes direkt nacheinander angeordnet in der Form 16 Bits 1. Plane, 16 Bits 2. Plane, 16 Bits, 3. Plane, 16 Bits 4. Plane. Auch hier mußte man für einen einzelnen Punkt viermal schreiben. Da die Planes aber direkt aufeinanderfolgten, konnte man anstelle der Adressierungsart "offset(Ax)" = Basisregister + Offset auch die etwas schnellere Adressierung "(Ax)+" = indirekt mit Postinkrement verwenden.

    Um Programme zu beschleunigen, hat man keine Routine geschrieben für alle Farben, sondern jede Farbe bekam ihre eigene Routine:


  • Als Gegenbeispiel werfe ich mal ein Carrier Command in den Ring wo im Worst Case die eine Hälfte des Bildschirms Himmelblau und die andere Hälfte Pazifikblau ist. Beim Fliegen auch gerne mal diagonal.

    Bzw. wenn ich bei Elite ein Polygon das horizontal eher schmal ist durch Rollen des Schiffes um 90° drehe dann wird es in der Regel horizontal eher breit.


    Ja vermutlich müsste man mit sowas wie RLE-Listen rumhantieren. Und der Aufwand steigt mit der Anzahl der Objekte pro Zeile. Die Frage ist wieviele Objekte hab ich denn überhaupt z.B. bei einem Elite ? Sterne, Sonne, Raumschiff, Rakete. Und wie werden Überdeckungen (die durch die Listenbearbeitung wegfallen) sonst gehandhabt ? Overdraw ? An den Rändern unden dann odern ? Wie schauts mit dem Löschen des Buffers aus ? Wenn man eh eine Liste hat, müssten nur die einzelnen Pixel gelöscht werden nicht der ganze Screen.


    Eine andere Frage ist: Was braucht das in Hardware? Und da sehe ich ein zusätzliches Farbregister, das mit der letzten Bitmap-Farbe gefüttert wird und einen Multiplexer der je nach Modus entweder das normale Farb-Register oder das Füll-Register selektiert. Sieht für mich sehr preiswert aus für eine Möglichkeit.

  • Bzw. wenn ich bei Elite ein Polygon das horizontal eher schmal ist durch Rollen des Schiffes um 90° drehe dann wird es in der Regel horizontal eher breit.

    Wobei Elite eigentlich mit reiner Vektorgraphik gearbeitet hat, wenn ich mich recht erinnere. Soll aber das Argument deshalb nicht invalidieren.

  • Als Gegenbeispiel werfe ich mal ein Carrier Command in den Ring wo im Worst Case die eine Hälfte des Bildschirms Himmelblau und die andere Hälfte Pazifikblau ist. Beim Fliegen auch gerne mal diagonal.

    Hierbei handelt es sich um Hintergrundgrafik, die anders behandelt wird als die Polygongrafik, d. h. es gibt dafür auch andere Malroutinen, die darauf ausgelegt sind, eine ganze Zeile mit einer Farbe zu füllen (Himmel oder Wasser/Boden) sowie bei der Horizontlinie entweder Wasser von links kommend und Himmel von rechts oder umgekehrt zu malen. Oftmals wird sogar nur eins von beiden neu gezeichnet, während der Bildschirm zu Beginn mit einer Farbe (Himmel oder Wasser/Boden) komplett gelöscht wird.

    Bzw. wenn ich bei Elite ein Polygon das horizontal eher schmal ist durch Rollen des Schiffes um 90° drehe dann wird es in der Regel horizontal eher breit.

    Aber nur, wenn Du schon sehr nah am Objekt dran bist. "Frontier" z. B. verwendet für jede Farbe ein paar Spezialroutinen, welche jeweils eine horizontale Linie ziehen mit max 16, 32, 48, 64 ... Punkten. Für sehr breite Linien gibt es dann keine eigene Routine mehr, sondern diese Linien werden in einer Schleife gemalt. Da solche Linien extrem selten sind, fällt dies nicht ins Gewicht, denn die häufigsten Linienlängen werden dafür mit den Spezialroutinen ziemlich schnell abgewickelt.

    z.B. bei einem Elite

    "Elite" hat eher wenig Objekte mit wenigen Flächen, weil es ursprünglich von den 8-Bittern kommt.. Guck DIr im Vergleich dazu mal "Epic" an oder "Virus", "Zeewolf" oder "Frontier". Die weisen viel mehr Polygone/Linien auf.

    Und wie werden Überdeckungen (die durch die Listenbearbeitung wegfallen) sonst gehandhabt ? Overdraw ?

    Ja, s. Maleralgorithmus.

    Wie schauts mit dem Löschen des Buffers aus ? Wenn man eh eine Liste hat, müssten nur die einzelnen Pixel gelöscht werden nicht der ganze Screen.

    Mag sein, aber auch hier gibt es den Punkt, an dem es aufwendiger wird, einzelne Pixel zu löschen (deren Koordinaten aus der Liste geholt werden müssen, die wiederum auch gelöscht werden soll) als rabiat den Hintergrund zu löschen. Die Frage ist nur, wann dieser Punkt erreicht ist. Darüber läßt sich an dieser Stelle nur spekulieren, weil schlecht abzuschätzen ist, wie aufwendig genau das Listenverfahren in der Praxis ist.

    Da es keine Hardware gibt, die auf die von Dir genannte Weise arbeitet, bleibt nur eine Möglichkeit: Emulator schreiben und austesten. Womit wir dann wieder beim Thema wären. Oder so wie es Daybyter formuliert:

    Wäre es nicht cool, wenn man einen Computer hätte, der mal ein Hallo ausgeben könnte? Nur mal so als Anfang, bevor ihr die Spiele plant?

    Da hat er wohl recht.