letzter Beitrag von Brechdurchfall am
Alles anzeigenDaher nochmal konkret und knapp:
288x160 Pixel in 320x180?
=HDMI/6
Für den Editor dann h/v das Doppelte.
Was meint Ihr?
Mein Vorschlag zur Game-Auflösung, der im Grunde den von ZeHa aufgreift, wurde vernommen?
(Eine Skalierbarkeit wie von Retrofan vorgeschlagen, würde ich nicht machen).
Der 'Editor' hätte 576x320 Pixel.
Platz und Retro genug und "quadratisch".🙂
ich waere fuer insgesamt quadratisch.
256x256.
Da waere fast alles drin 
160 x 144 Gameboy
160 × 102 Atari LYnx
160 x 160 Watara Supervision
240 x 160 GBA
256 x 240 NES
384 × 224 Virtual Boy
256 x 239 PC Engine (*)
320 × 224 PC Engine
256 x 224 NEC PC-FX
Ein anderer Ansatz um niedrige Auflösungen "aufzuwerten" könnten (gefüllte) Vektor-Sprites oder -Chars sein...
Also dass das System zusätzlich zur normalen Pixelgrafik etwa eine begrenzte Anzahl von Vektoren bereitstellt die an Punkten der nativen niedrigen Auflösung anfangen und aufhören können, die Linien (Vektoren) dazwischen aber fein in der hohen Auflösung des Bildschirms dargestellt werden.
Hätte einen eigenen, unverwechselbaren Look.
(ähnlich Vectrex, aber viel besser)
ich waere fuer insgesamt quadratisch.
256x256.
Es geht um quadratische Pixel in einem 16:9-Umfeld.
Andere Systeme sind nicht relevant.
ob der Code chinesischer Entwickler in Programmiersprachen, wie C++ oder VB in chinesisch editiert wird. Verwenden die nicht auch teilweise "ASCII"?
Ich habe schon mehrmals Code mit englisch(-artigen) Variablennamen und asiatischsprachigen Kommentaren gesehen.
256 x 239 PC Engine (*)
320 × 224 PC Engine
Da gehen horizontal bis zu 512 Pixel. Wenn es dir nur darauf ankommt ob die Konsole wenigstens einen Modus besitzt, der in 256x256 ohne Beachtung des PAR passen würde: Mega Drive hat einen 256-Pixel-Modus und beim SNES fühlt sich die Option auf 512 Pixel horizontal IIRC eher wie ein Half-Pixel-Hack als ein richtiger 512er-Modus an.
Eine Skalierbarkeit wie von Retrofan vorgeschlagen, würde ich nicht machen
Ich glaube, du hast meinen Vorschlag nicht verstanden. Ich bin nach wie vor für eine feste Gaming-Auflösung – und die sollte nach wie vor 320 x 176 px betragen. Was variabel werden würde, wäre die Größe des Randes – von Null bis keine-Ahnung.
ich waere fuer insgesamt quadratisch.
256x256.
Wir müssen dann nur noch quadratische Bildschirme mitliefern. 
Ein anderer Ansatz um niedrige Auflösungen "aufzuwerten" könnten (gefüllte) Vektor-Sprites oder -Chars sein...
Also dass das System zusätzlich zur normalen Pixelgrafik etwa eine begrenzte Anzahl von Vektoren bereitstellt die an Punkten der nativen niedrigen Auflösung anfangen und aufhören können, die Linien (Vektoren) dazwischen aber fein in der hohen Auflösung des Bildschirms dargestellt werden.
Hätte einen eigenen, unverwechselbaren Look.
(ähnlich Vectrex, aber viel besser)
Ein interessanter Ansatz. Vectrex ist auch retro. Passt aber hier imo nicht so ganz, da explizit "Pixelgrafik" gewünscht ist.
Und mit so einer Umvektorisierung wäre wohl ein Großteil der begrenzten Rechenleistung alleine schon gut beschäftigt.
Ist fuer 16:9 dann nicht WQVGA? Wieso das Rad neu erfinden?
480x234
Ist fuer 16:9 dann nicht WQVGA? Wieso das Rad neu erfinden?
480x234
Diese Aufloesung ist zum einen zu hoch, zum anderen nicht 16:9
Die Diskussion um dieses Projekt gibts ja schon seit Jahren, da gab es einige Denkprozesse, Ideen und Entscheidungen, die dazu gefuehrt haben, dass die horizontale Aufloesung unter 400, am besten jedoch nicht hoeher als 320 sein sollte. Zumindest fuer den "Game"-Modus (der Text/IDE-Modus soll die doppelte Aufloesung bekommen)
Das sind zwei sehr unterschiedliche Baustellen in einem Argument. Nur weil etwas Open Source ist bedeutet das noch lange nicht, dass es einfach so auf einem Pi400 und einem aktuellen PC startbar ist (umgekehrt genauso).
das hat ja auch gar keiner behauptet 
Wieso das Rad neu erfinden?
Weil das u.a. ZeHa (alles nahe an 400 ist schon zu viel) und auch mir zu hoch erscheint. Und da wir bei einem neuen Computer die Auflösung neu denken dürfen, sind wir freier und müssen auf keinen "Standard" setzen, für den es eine kryptische Buchstaben-Kombination gibt. (ja, ich weiß, was das heißt).
Bisher waren unsere Vorgaben: In beide Richtungen durch 8 (besser noch durch 16) teilbar und ganz nah dran am Optimum wäre ein glatter Teiler der Full-HD-Auflösung (ob in jeder Richtung der gleiche, sei dahingestellt). Wobei letzteres immer mehr obsolet wird – "dank" der Overscan-Problematik und auch, weil der Trend immer mehr in Richtung 4K und 8K geht, wo man wirklich nicht mehr erkennt, ob nun ein großer Pixelblock aus 12, 12,5 oder 13 horizontalen Sub-Pixeln besteht. Was aber bestehen bleibt, ist das 16:9-Seitenverhältnis der vorhandenen Fernseher – dieses sollte man schon versuchen, gut zu füllen, damit das ganze nicht wie ein Skalierungs-Unfall aussieht.
Ich habe schon mehrmals Code mit englisch(-artigen) Variablennamen und asiatischsprachigen Kommentaren gesehen.
Kann sein. Ich sagte ja, dass ich nicht weiß, welche Sprache chinesische Programmierer beim Coden verwenden. Aber ich sagte ja auch, dass mich das gar nicht so sehr interessiert. Ich glaube nicht, dass man einen China-Vertrieb für einen/diesen europäischen Computer so einfach auf die Beine gestellt bekäme – der Markt wäre aus meiner Sicht also ohnehin verschlossen. Und was die mit der OpenSource-IDE anstellen würden, um da ihre Zeichen reinzubekommen, muss mich nicht interessieren.
Ich gebe auch gerne zu, dass ich die "chinesischen" Apps/Games im iOS App Store ausgeblendet habe, weil mich die einfach nicht abholen – u.a. auch, weil sich viele chinesischen Programmierer offensichtlich einen Kehricht um UNSER Zeichensystem oder Sprache kümmern. Ob die dort also für meinen Lieblings-Computer Programme schreiben wollen, interessiert mich wirklich nicht so sehr – ich hindere sie daran aber auch nicht. Bei den Japanern sehe ich das durchaus anders – die haben schon immer interessante Spiele entwickelt, die auch auf westlichen Märkten "funktionieren". Und es spräche nichts dagegen, wie der PICO-8, japanische Zeichen (ich nehme an, Kanji) zu unterstützen.
Aber wie gesagt: Es geht hier um einen Computer. Märkte, auf denen der nicht verkauft wird (nicht verkauft werden kann), sind für uns zweitrangig, da dort auch kein Interesse an (kostenloser) Software-Entwicklung für das Gerät zu erwarten wäre.
vielleicht sollte man da mal klare Bezeichnungen schaffen - dann nennen wir den einen "Text"-Modus und den anderen "Game"-Modus? Oder eben "Hires" und "Lores"?
Das hinge halt auch ein wenig von den Eigenschaften und vom Kontext ab. Wenn wir uns darauf einigen können, dass es in der IDE keinen hochauflösenden "Linux"-GUI-Mode geben wird und auch sonst nirgendwo die (natürlich höhere) native Hardware-Auflösung thematisiert wird (außer in Verbindung mit dem HDMI-Output), können wir gerne von Hires und Lores sprechen. Wenn klar ist, dass "Hires" nur bei "echtem, unveränderlichen" Text möglich ist, passt hier natürlich auch (vielleicht besser) Text-Modus.
vielleicht sollte man da mal klare Bezeichnungen schaffen - dann nennen wir den einen "Text"-Modus und den anderen "Game"-Modus? Oder eben "Hires" und "Lores"?
Das hinge halt auch ein wenig von den Eigenschaften und vom Kontext ab. Wenn wir uns darauf einigen können, dass es in der IDE keinen hochauflösenden "Linux"-GUI-Mode geben wird und auch sonst nirgendwo die (natürlich höhere) native Hardware-Auflösung thematisiert wird (außer in Verbindung mit dem HDMI-Output), können wir gerne von Hires und Lores sprechen. Wenn klar ist, dass "Hires" nur bei "echtem, unveränderlichen" Text möglich ist, passt hier natürlich auch (vielleicht besser) Text-Modus.
Das stimmt, aber ich denke man braeuchte auch fuer die weitere Diskussion 2 klare Begriffe, diese muessen ja nicht final sein. Aber damit man sich halt nicht immer wieder erklaeren muss. Vielleicht auch Game- und IDE-Modus, oder Game- und Application-Modus? Game- und Work-Modus?
Game- und Work-Modus?
Es hängt eben auch ein wenig davon ab, welche Einschränkungen man vergibt. Wenn man sagt, überall (auch in eigenen Games/Apps) wäre der Mode (mit den genannten Einschränkungen) nutzbar, dann wäre es kein wirklicher Work/IDE-Mode. Wenn man aber sagt, der Mode wäre nur für den Code-Editor-Bereich nutzbar, dann könnte man ihn natürlich so vom Rest absetzen.
Ich glaube, du hast meinen Vorschlag nicht verstanden. Ich bin nach wie vor für eine feste Gaming-Auflösung – und die sollte nach wie vor 320 x 176 px betragen. Was variabel werden würde, wäre die Größe des Randes – von Null bis keine-Ahnung.
Doch, ich denke schon.:)
Du erlaubst ein "Spielfeld" von 320x176 auf 320x180 BIS abc x def auf 320x180.
Optionen verunsichern Menschen.
Daher würde ich (wie weiter oben geschrieben):
a) 320x176 auf 320x180 ("Overscan ist Schnee von gestern")
ODER
b) 288x160 auf 320x180 ("Overscan-wenn es denn sein muss")
festlegen.
Es soll ja einen einheitlichen Look geben und eine fixe Auflösungvorgabe hilft dabei.
Beim Editor, Text, IDE, Creativity oder wie man diesen Modus auch nennen mag, die 2x2-fache Auflösung OHNE Farbeinschränkungen. Wie soll man AUF dem Hänsel-2000 im TitelbildeditorPRO sonst pixeln können?
Diese Auflösung funktioniert nur hier und basta. Nicht im Spielemodus.
Diese Auflösung funktioniert nur hier und basta. Nicht im Spielemodus.
Die Frage ist dann nur, was ist wenn jemand z.B. eine zusaetzliche App programmieren moechte. Zum Beispiel einen alternativen Titelbild-Editor, oder Sprite-Editor, oder oder oder... dann waere es cool, wenn man auch eine App fuer den "Hires"-Modus entwickeln koennte. Allerdings wuerde das natuerlich keinen davon abhalten, darin z.B. ein Spiel zu schreiben. Aber vielleicht kann man das dann auch einfach erlauben und gespannt sein, was die Leute draus machen.
Unter DOS gab es auch eine handvoll Spiele in 640x480, die sahen aber oft grausig aus. Die meisten waren dennoch in 320x240.
Bin auch dafür dass der Hires-Modus auch für eigene Programme (und Spiele) zur Verfügung stehen sollte.
Als Programmierer würde ich mich bevormundet fühlen wenn ich wüsste, dass der Computer einen Grafikmodus beherrscht, der vielleicht etwas kann was ich gerade bräuchte, ich ihn aber aus künstlichen Gründen nicht nutzen könnte.
Das würde zudem heißen, dass es keine Möglichkeit gäbe, die IDE direkt auf dem Computer (weiter) zu entwickeln.
(Übrigens hatten die meisten DOS-Spiele eine Auflösung von 320x200 mit Pixelseitenverhältnis von 1:1,2.)
(Übrigens hatten die meisten DOS-Spiele eine Auflösung von 320x200 mit Pixelseitenverhältnis von 1:1,2.)
Ah, das erklaert warum mir die Pixel bei Monkey Island, als ich das das erste mal bei meinem Kumpel gesehen habe, so hochkantig vorkamen
Es gab auf jeden Fall ein paar Exoten in 640x480 (oder 640x400), die sahen aber oft komisch aus - zumindest die, die ich so kenne (z.B. von "Moraff" oder "Soleau" Software). In dem Modus haette ich jedenfalls kein Spiel schreiben wollen
Beispiele:
Wie soll man AUF dem Hänsel-2000 im TitelbildeditorPRO sonst pixeln können?
Man könnte, ähnlich wie beim KoalaPainter, zwei umschaltbare Bildschirmseiten verwenden:
Eine im "Multicolor-Modus", um das Bild zu sehen und zu bearbeiten und eine im "Textmodus" für die Toolbox und ggf. weitere IDE-Elemente.
