Hello, Guest the thread was viewed18k times and contains 154 replies

last post from Brechdurchfall at the

Welche Grafikauflösung für einen theoretischen Retro-Computer mit HDMI-Output?

  • Nur bei der Auflösung werden wir uns wohl nie einig werden. Ich halte eine etwas höhere Auflösung, die dafür aber quadratische Pixel hat, für einfacher zu befüllen als eine mit "Multicolor-Pixeln". Geht man von einer 8x8 Matrix aus und der Verwendung auf 16:9 Full-HD Displays, bleiben da nicht allzu viele Varianten übrig.

    Ich bin jetzt nicht alle alten Threads durchgegangen, um zu gucken, was wir schon mal diskutiert haben. Aber ich experimentiere gerade mit einer Spiele-Auflösung von 320 x 176 px, die mit etwas schwarzem Rand (je 2 px oben und unten) auf 320 x 180 px aufgefüllt und dann kantenscharf auf Full HD (Faktor 6) hochskaliert wird. Das sind quadratische Pixel, wie du sie gerne hättest und ein Vielfaches von 8 und durch das Auffüllen ein Teiler von Full HD. Die Auflösung ist vertikal etwas geringer als bei Amiga (US) und Atari ST. Ich will mal sehen, wie das auf einem Flat-TV aussieht.


    Die Pixel-Anzahl (320 x 176 = 56.320 px) ist nicht so weit weg (+8,5%) von meiner bisher favorisierten "Multicolor"-Auflösung von 240 x 216 (51.840 px).




    Edit: Dieser und die ersten (rund 25) Beiträge stammen ursprünglich aus dem Thread:

    Möchte man direkt auf einem (modernen) Retro Computer programmieren?


    Vorhergehende Threads mit ähnlicher Thematik:

    Konzept eines Retro/Home-Computers (als Software auf Raspi)

    Ein Retro-Computer als Emulation/VM auf dem Raspberry Pi (inkl. Game-IDE und Programmiersprache)

    Neuer Retro-Computer im 8-Bit Style

  • Ich meine, was ich damals vorgeschlagen hatte, wäre komplett ohne Rahmen, also exakt 16/9 und h/v durch 8 teilbar gewesen.

    Aber die Pixelanzahl war Dir zu hoch.


    War es 384x216?


    Jeder Retropixel wäre genau 5x5 HD-Pixel.


    Mein Argument war, dass die Pixeldichte nicht höher wäre als C64 Hires, da der Rahmen wegfällt bzw. hier befüllt werden kann.

    Und das Bild dann später auch auf keinen 63 cm Röhren-TV angeschaut werden muss sonder auf einem >50" Flatscreen.


    Ein Kompromiss wäre die Option, ob man die 384x216 voll nutzt oder ob man lieber einen Rahmen hat und nur 320x☆☆☆ Pixel befüllen will.

    Oder ob man "Multicolor" Pixel mit 192x216 nimmt. ICH würde diese Option nicht nutzen wollen.

    Aber die 'native Auflösung von 384x216 macht imo schon viel Sinn. :)

  • Ein Kompromiss wäre die Option, ob man die 384x216 voll nutzt oder ob man lieber einen Rahmen hat und nur 320x☆☆☆ Pixel befüllen will.

    Dir wären 320x180 mit einem fetten Rahmen lieber als die gleiche Auflösung Fullscreen? Wofür der Rahmen – Zum Verkleinern des Bildes?

  • Mir wäre 384x216 am liebsten.

    Weil das von den Chars, Skalierfaktor und rahmenlos perfekt passt.


    Der Rahmen wäre für 'Dich' für weniger Pixel.😉


    320x 180 geht Char-mäßig nicht auf. Da rebelliert mein innerer Monk.

    Eben so, wenn man 176 nimmt und oben/unten minimale Balken beommt.:nixwiss:


    Am besten mal ne Umfrage machen? Auch mit der Antwortuntetscheidung in Anwender/Ersteller.

  • Der Rahmen wäre für 'Dich' für weniger Pixel

    Das ist doch quatsch. Und 64 x 64 px für ganz "faule"? ;)


    Wenn man eine hohe Auflösung ohne Einschränkungen (wie z.B. reduzierte Farbanzahl) anbietet, werden einige diese nutzen und die anderen Games wirken dann "minderwertig". Es geht doch bei so einer Plattform darum, dass ALLE die gleichen (geringen) Voraussetzungen haben. Sonst könnte man einfach eine ganze Anzahl von Modi bis hin zu Full-HD anbieten und frei auswählen lassen. NATÜRLICH versuchen dann alle, die hohen Auflösungen zu nutzen, weil sie nicht gegen die anderen abstinken wollen – und schon sind wir in der Falle, in die wir nicht tappen wollten.


    Mir wäre 384x216 am liebsten.

    Weil das von den Chars, Skalierfaktor und rahmenlos perfekt passt.

    Ich kann ja auch rechnen und bin auch alle Möglichkeiten durchgegangen (x4, x5, x6 ...). Natürlich passt das schön ins Rechenschema und sind hübsche Zahlen – wie übrigens auch meine "Multicolor"-Auflösung, nur mag dein Monk eben nicht nur keine kleinen Ränder (während große OK zu sein scheinen), sondern auch keine Pixel-Seitenverhältnisse außer 1:1. ;)


    Und es geht eben nicht nur darum, schön glatte Zahlen zu haben, sondern darum, möglichst praktikabel für die Leute zu sein, die Content erstellen. Sind die 7x7-Chars beim Apple II schön? Ist Ataris Auflösung von 320 x 192 < (hallo, da fehlt doch eine Zeile) schön? Sind beim C64 38 (statt der üblichen 40) Chars beim horizontalen Scrollen schön? Nachdem es so gemacht wurde, ist es, wie es ist.


    Am besten mal ne Umfrage machen?

    Noch mehr Leute fragen, die vielleicht nur hochauflösende Titelbilder und Demos haben wollen und sich nicht darum scheren, wie der Grafiker die Spiel-Fläche vollbekommt? ;) Ich weiß nicht. Letzten Endes kommen wir dann doch, wie die existierenden Plattformen, bei 640 x 480 @ 256 Farben heraus.


    ---


    Bei der Farbanzahl ist es doch ganz ähnlich: Wie oft habe ich schon gehört: Warum nur 16 Farben, nimm doch 32 … oder 64 … oder 128 … oder 256 … und am besten aus einer noch größeren Palette, wie 4096 … oder noch mehr. Natürlich sehen 32 Farben besser aus als 16 – das ist doch keine Frage. Die Frage ist doch: Wie weit kann man runtergehen, ohne dass es schmerzt.


    Mein Ansatz bei der Idee ist nicht "mehr ist mehr", sondern "weniger ist mehr". Also das auszuwählen, was gerade noch als attraktiv wahrgenommen werden könnte und gleichzeitig den Content-Ersteller entlastet. Jede noch geringere Auflösung, die auch noch auf dem TV "funktionieren" könnte, wäre mein Favorit.


    Und manchmal tut es natürlich weh – und machmal muss man es aushalten. Wie auch überhaupt bei dem von mir recht früh favorisierten 16:9-Seitenverhältnis. Ich war ja lange Zeit gefühlt der Einzige, der überhaupt dieses moderne TV-Seitenverhältnis propagiert hat. Die meisten anderen sagten: Nein, 4:3 ist bei "retro" das einzig denkbare (und ja auch das, was die anderen Plattformen anbieten).


    Natürlich ist keine einzige Auflösung wirklich vom Tisch, schon alleine, weil letzten Endes der entscheidet, der so einen Computer wirklich bauen will. Ich habe nur die Befürchtung, dass bei Auswahl einer höheren Auflösung viele später sagen werden: Hätten wir mal auf dich gehört und eine geringere genommen – weil die Spiele dann ein paar Wochen schneller fertig wären. Der Coder, der auch Grafiker ist, sitzt jetzt länger als nötig an den Grafiken und kommt so weniger zum Programmieren.


    Es ist also nicht so, dass ich 384 x 216 px nicht mögen würde – ich habe die Auflösung selbst für mich schon recht früh zu meinen Lieblings-Kandidaten erkoren – nur ist mein Antrieb hier: So wenig, wie irgendwie möglich.

  • Man kann solche Sachen überhaupt nur beurteilen, wenn man sie sieht.



    Zentraler Punkt bei der hier diskutierten Plattform ist die IDE. Ausgangspunkt ist die PICO-8 IDE, die auf 128 x 128 px festgelegt ist. Die Spiele-Grafiken in dieser Auflösung sehen gut (und schön pixelig) aus und lassen sich schnell erstellen. Die Kachel-Größe ist 8 x 8 px, sodass die Fläche aus 256 Kacheln besteht. Jede Auflösungserhöhung ist natürlich mit mehr Aufwand/Zeit beim Erstellen der Grafiken verbunden.


    In rot sieht man die deutlich höhere Auflösung des TIC-80-Projekts, das glücklicherweise auch schon auf das 16:9-Seitenverhältnis setzt. Hier sind 510 Kacheln zu füllen, was ca. das Doppelte gegenüber dem PICO-8 ergibt.


    In blau sieht man meinen derzeitigen Favoriten: Full-HD/6. Das ist natürlich schon DEUTLICH (3,5 mal) mehr als die PICO-8-Auflösung. Und die Kachel-Auflösung habe ich bisher nicht erhöht – sie bleibt bei 8 x 8. Das ergibt dann 880 Kacheln.


    In dunkelgrün sieht man die übliche 16/32-Bit Farb-Auflösung von Atari ST- und US-Amiga-Games. Das wären genau 1000 Kacheln. Der C64 kann die Auflösung auch erreichen, dann allerdings mit stark eingeschränkter Farbauswahl (2 Farben je Kachel), für die meisten Games also unbrauchbar. Atari 8-Bit bleibt bei einer ähnlichen Auflösung sogar monochrom.


    In grün sieht man die Full-HD/5-Auflösung. 48 x 27 = 1296 Kacheln. Das sind schon 5 mal so viele wie beim ursprünglichen PICO-8, von dem wir uns ja hier inspirieren lassen.


    Das zeigt vielleicht mein Problem mit den höheren Auflösungen. Selbst mein Favorit hat schon eine massiv höhere Auflösung als das Referenz-Projekt. Eine einzelne Kachel wirkt da schon etwas verloren. Bei noch höheren Auflösungen wird das natürlich schlimmer. Natürlich kann man auch sagen: Jetzt ist es eh schon egal, dann nehmen wir eben das 5-fache. Jede Auflösungs-Entscheidung hätte ihre Berechtigung (auch die mit nicht-quadratischen Pixeln, die ich hier außen vor ließ).

  • Für Dich ist das Pico-8 die Referenz.

    Für mich eher ein C64 Hires-Bild, dargestellt auf einem Full-HD Screen.


    Wie gesagt, ich schaue mir die 176 Zeilen mal an. Wenn es ok ist, dann muss Monk halt mit den verlorenen Zeilen irgendwie umgehen.

    Es wäre jedenfalls imo für die Erstellung von Content schon mal eine riesen Erleichterung, keine 1,6x breite Pixel zu haben.🙂


    Edit: hat der PAL Amiga nicht (auch/eigentlich) 320x256?

  • Ich habe auch schon mit einigen solchen Aufloesungen herumexperimentiert, und ich hatte da zum Teil auch den Eindruck, dass alles, was in Richtung 400 Pixel Breite geht, schon wieder "zu viel" ist. Allerdings faende ich z.B. auch die Idee mit 384x216 nicht schlecht, wenn man darin dann wirklich einen Rand setzt - um ggf. den Overscan eines Fernsehers ein wenig abzufangen. Aber diese Diskussion hatten wir auch schon im urspruenglichen Thread. Man koennte z.B. auch 360x200 nehmen, und in einer 384x216-Flaeche anzeigen, dann haette man nur ein bisschen Rand. Ein wenig unschoen ist dann aber, dass man 45 Character Breite haette (irgendwie tendiere ich da halt doch immer zu durch 8 teilbaren Zahlen, wie z.B. 40, 48, 32, usw - auch wenn das beim New-Retro-Computer 2000 vielleicht nicht mehr soo wichtig ist).


    320x176 habe ich auch schon hin und wieder genutzt und fand ich eigentlich super, bis auf diese haesslichen Mini-Raender oben und unten. 320x180 waere bildschirmfuellend, aber dann hat man einen halben Character, das ist auch wieder doof.


    Letztendlich halte ich es so, wie mein Physik-Lehrer immer zu sagen pflegte: Die Vertreibung aus dem Paradies ist allgegenwaertig ;)

  • Zum Thema quadratische vs. nicht-quadratische Pixel wollte ich auch nochmal was sagen (es gab ja mal die Idee, die Chars in 5x8 zu machen oder so, und diese dann aber in einer Breite anzuzeigen, die 8x8 entspricht). Da habe ich testweise auch mal ein bisschen rumgepixelt, und ich hatte das Gefuehl, dass ich am Ende nicht anders pixle als ich das auch auf einem "normalen" Raster machen wuerde. Nur dass die Figuren / Tiles dann halt ein bisschen gestaucht oder gestreckt aussehen. Also auch wenn ich die Idee an sich interessant faende, ich koennte mir vorstellen dass das nur wenige Grafiker so nutzen wie Retrofan sich das gedacht hat, sondern dass die meisten einfach "ganz normal" pixeln und die Grafik dann halt ein bisschen wie auf dem VC-20 aussieht oder so :)

  • hat der PAL Amiga nicht (auch/eigentlich) 320x256?

    Ja , hat er. Deswegen sprach ich ja immer vom US-Amiga, der sich die Auflösung mit dem ST teilt. Und auch die meisten Action-Games, die ich vom Amiga so kenne, setzen auf die 320x200er Auflösung und ließen bei PAL unten einen dicken schwarzen Balken frei.


    ---


    Meine obige Argumentation kommt aus Richtung der IDE und Grafikerstellung. Ich möchte aber auch nochmal aus einer anderen Richtung argumentieren.


    Neben der IDE war ein weiterer Startpunkt, beim Spielen ein 8-Bit-Feeling aufkommen zu lassen. Ich sprach ja von Anfang an von "8-Bit-Style". Und die üblichen 8-Bit-Auflösungen in Games waren 160 x 200 px (C64, Atari) oder auch 256 × 224/240 px (NES) – immer in die Breite gezogen. 320 x 200 (Hires) kannte man vom C64 vornehmlich für "trockene Anwendungen", wie GEOS, BASIC, Vizawrite. Die eingeschränkte Farbdarstellung in Hires war für Games nicht sehr attraktiv, weswegen wahrscheinlich 95% der Spiele auf 160 x 200 (Multicolor) px setzen.


    320 x 200 px war DIE Spiele/Farb-Auflösung der 16/32-Bit-Systeme von Commodore und Atari. Das ist ein weiterer Grund, weswegen ich 384 x 216 px für recht viel halte. Das liegt halt über dem, was man von den 16/32-Bit-Games kennt.


    Mein Ansatz war: Komfortabler als in den 80ern entwickeln – dafür bei den Multimedia-Specs einschränken. Natürlich sind 384 x 216 immer noch weniger als das, was so gerne genommen wird: VGA mit 640 x 480 – was ich ja für total übertrieben halte. Aber wenn man ein 8-Bit-Feeling erzeugen will, dann ist Full-HD/6 doch immer noch recht "üppig".

  • Da habe ich testweise auch mal ein bisschen rumgepixelt, und ich hatte das Gefuehl, dass ich am Ende nicht anders pixle als ich das auch auf einem "normalen" Raster machen wuerde. Nur dass die Figuren / Tiles dann halt ein bisschen gestaucht oder gestreckt aussehen.

    Das ist so. Das ist übrigens bei ganz vielen C64/Atari-Games so. Man versuchte ja auch öfters, Arcade Games mit Portrait-Darstellung auf den quer stehenden Heim-TV zu "quälen". Man kann sich dazu z.B. die ganzen Donkey Kong-Portierungen ansehen. Da wird massiv gedrückt und gestaucht. Ich glaube, dass man das nach kurzer Zeit gar nicht mehr so wahrnimmt – man nimmt einfach hin, dass die ganzen Spielfiguren teils breiter als hoch sind (siehe auch Sam's Journey oder deine Games), auch wenn das bei echten Menschen nur selten vorkommt (klar, mit Ausnahmen). ;) Das ist also keine VC-20-Eigenart, sondern dort nur besonders extrem.


    shotgun-sprite.png


    Bei meinem "Multicolor"-Auflösungsvorschlag sind die Pixel aber weniger stark in die Breite gezogen, als z.B. beim C64, sodass die Verzerrungen geringer ausfallen, als wir das gemeinhin kennen.


    DER Effekt würde mich also nicht stören. Was mich am ehesten an 240 x 216 auf Full-HD gestört hat, war, dass man meinen könnte, das Bild wäre für 4:3 gemacht und dann unbeabsichtigt auf 16:9 verzerrt worden. Man hätte es vielleicht für eine fehlerhafte Skalierung halten können. DAS hat mich am Meisten dabei gewurmt, weswegen ich nochmal "zurück an die Werkbank" gegangen bin und nach anderen Auflösungen gesucht habe.

  • Hier einfach nochmal 'ne andere FullHD-kompatible Aufloesung mit nicht so grossem Rand. 288x160 in einem 320x180-Fenster (also 1920 und 1080 jeweils durch 6). Der Rand koennte dem Overscan eines TVs zugute kommen (falls jemand nicht weiss dass man den abschalten kann), und ich finde so einen farbigen Rand eigentlich auch charmant, allein schon zum Debuggen oder fuer simple Effekte.


  • Und wie wäre es bei 16x16-Kacheln?

    Es wären dann natürlich entsprechend weniger Kacheln. Aber die Kacheln selber wären aufwendiger zu füllen (was vielleicht den einen oder anderen Hobby-Pixler überfordert), immerhin sind 4 mal so viele Pixel zu setzen. Und dann ist auch die Frage, wie man mit Schrift umgehen will. Dafür auch die großen Tiles oder speziell dafür 1/4-Tiles? Ab irgendeiner Auflösung muss man zwangsläufig die Tile-Größe anheben – die Frage ist halt, wo man die Grenze zieht oder ob man vielleicht auch mal auf ungewöhnliche Größen, wie 12 x 12 setzen mag.


    Dann wäre auch nicht mehr die Frage, ob eine Auflösung durch 8, sondern durch 12 oder 16 teilbar ist.

  • Der Rand koennte dem Overscan eines TVs zugute kommen (falls jemand nicht weiss dass man den abschalten kann)

    Overscan macht mir nach wie vor am meisten Sorgen. Ich hatte das gestern nochmal ausgetestet mit meiner iPhone-HDMI-Präsentations-Lösung. Der (Samsung) TV stellte per default das Full-HD-Signal im Overscan-Modus dar, ließ also an den Rändern Pixel verschwinden. Übers Menü konnte ich eine Voll-Darstellung erzwingen, die dann sehr gut aussah. Aber wie du schon sagst, kommt damit nicht jeder klar.


    Das Problem ist, dass unsere ganze Rechnerei um Vielfache und Teiler komplett egal wird, wenn der Fernseher nicht 1920 x 1080 px 1:1 auf 1920 x 1080 px darstellt, sondern einfach lustig um ein paar Pixel hochskaliert. Es wird dann ohnehin unscharf und es ist ab dann vollkommen egal, ob ein Pixel auf 6 x 6 Full-HD-Pixel (die dann eh nicht getroffen werden) oder gleich auf 5,7 x 5,7 Pixel trifft.


    Deswegen: Wenn sich herausstellt, dass eine überwiegende Anzahl von TVs bei einer externen Computerquelle im Overscan-Mode verbleibt, können wir die umständliche Rechnerei auch sein lassen.


    (Mir ist nach wie vor nicht klar, was die Hersteller reitet, Full-HD nicht auf genau der dafür vorgesehenen Auflösung darzustellen, sondern einfach zulasten der Schärfe ein bisschen hochzuskalieren. Was meinen die, was mit den Randpixeln nicht OK sein könnte, sodass man sie lieber nicht zeigt? Videodat-Gekräusel?) ;)

  • Aber dann waere doch ein solcher Rand, der nicht zu dick auftraegt (also laengst nicht so krass wie beim C64) doch eigentlich eine charmante Loesung, oder nicht? Ich finde so einen Rand halt auch irgendwie "retro", und in manchen C64-Spielen ist der Rand ja z.B. auch bewusst farbig und nicht einfach nur schwarz.


    Grundsaetzlich, was die Aufloesung angeht, hatte ich gerade den Gedanken dass es vermutlich ideal waere, wenn Spiele sowohl mit 8x8 grossen Tiles als auch mit 16x16 grossen Tiles gut aussehen wuerden. Bei PICO-8 z.B. verwenden die meisten 8x8, weil es bei der niedrigen Aufloesung von 128x128 einfach naheliegend ist. Auf dem C64 wiederum sehen Spiele mit 8x8-Tiles schon fast ein bisschen "fitzelig" aus, und ich wuerde mal behaupten, ein Grossteil der Spiele orientiert sich da eher an 16x16. Wenn die Aufloesung nun irgendwo dazwischen liegt, sodass beide "Arten" von Spielen cool und souveraen aussehen, dann waere das vielleicht der "Sweet Spot".


    Bei TIC-80 funktioniert beides gut, wie dieses Video hier schoen zeigt:

  • Wenn sich herausstellt, dass eine überwiegende Anzahl von TVs bei einer externen Computerquelle im Overscan-Mode verbleibt

    HDMI-Quellen müssen (fast) immer ein Video-Infoframe mitsenden, in dem diverse Details zum übertragenen Signal mitgeteilt werden. Darunter befindet sich zB ob Overscan verwendet werden soll, das Seitenverhältnis des Bilds oder auch ob es sich um ein Spiel handelt und daher geringe Latenz wichtig ist. Je nach Fernseher werden verschiedene Subsets davon korrekt ausgewertet, aber ich habe keine solide Datenbasis um da Vorhersagen zu machen, insbesondere nicht für Overscan.


    Und dann ist auch die Frage, wie man mit Schrift umgehen will. Dafür auch die großen Tiles oder speziell dafür 1/4-Tiles?

    Variante 1: Die Hardware verwendet 8x8-Tiles, die Software implementiert damit 16x16 - auf dem C64 gibts da doch diverse Präzedenzfälle

    Variante 2: Die Hardware hat mehrere Tile-Layer mit unterschiedlichen Tile-Grössen, Text schreibt man in den 8x8-Layer und Grafik macht man im 16x16-Layer. Das SNES hat zB vier Tile-Layer, die unabhängig voneinander konfigurierbare Tile-Grössen haben. Selbst das Neo Geo, das von der Architektur her eigentlich auf die Anzeige von sehr vielen sehr grossen Sprites optimiert war und damit sogar die Hintergründe zusammensetzt hat einen zusätzlichen 8x8-Tile-Layer, der zB für Score-Anzeigen verwendet wird.

  • Ein weiteter Beweggrund von mir für die relativ "hohe Retroauflösung "ist, dass man das auch etwas weiter/größer spinnen könnte.


    Als Retrocomputer spricht man vermutlich verstärkt die Generation Ü50 an.


    Wenn man das ganze aber als moderne, günstige, zeitlose und vaD. leicht zu bedienende Mitmachspielekonsole platziert, holt man vielleicht ein wesentlich breiteres Publikum ab. Auch einige der Smartphone-Zombies, die mal selbst was erstellen wollen statt nur zu konsumieren.


    Es ist quasi, wie das Vorbild Pico-80, nur "in echt" für den TV als Konsole (+Tastatur = Entwicklungscomputer) zum Zocken.


    Eigene Games können als echte Releases mit Box Art und Pipapo vertrieben werden (Medium: USB-Stick), wenn man das möchte.


    Und für eine jüngere Generation ist eine Auflösung von 384x216 ( wir sprechen vom 1/25tel der HD-Auflösung) sicher noch immer "retro" genug. Die juckt nicht, was C64 und Co hatten. Die Auflösung ist einfach so, um es einfacher zu machen. Das (durch mehr Pixel etwas kleiner gewordene) Retrofeeling ist ein Bonus für uns alten Säcke. :)


    Wenn man es noch weiter spinnen will, könnte man später auch eine Handheld-Version herausbringen.


    Solche Betrebungen/Lösungen zum Pico gibt's imo ja durchaus auch.