last post from wizball6502 at the
Auch hier noch eine zweite Variante mit Testprogramm. Bei einem Mix von MC und Hires spart man weitere 2 Taktzyklen pro dargestelltem Char, weil "OR #$08" entfallen kann.
Der Nachteil:
In jeder der 8 Farben sind nur noch maximal 16 unterschiedliche Hires- und maximal 16 unterschiedliche MC-Zeichen möglich.
Finde diese Idee grundsaetzlich ziemlich cool... klar, man muss seine Chars evtl. ein bisschen anders organisieren, aber fuers Scrollen zahlt es sich definitiv aus... coole Idee 
Ich denke gerade über einen Ansatz mit einen fake 3D Effekt nach.
Und zwar überlege ich, statt mit Chars, mit Sprites zu arbeiten. Diese lassen sich recht einfach in alle Richtungen inkl. Farben bewegen.
Damit es einen 3D Effekt erzeugt, könnte man eine Char Maske, die über den Sprites liegt verwenden, um die Sprites insoweit zu überdecken.
Die Maske könnte in etwa so aussehen (wobei die Chars dann in Hintergrundfarbe sein müssten):
Wenn diese Maske oben und Unten jeweils verändert wird, kann man damit die Geländeerhebungen vortäuschen. Die Sprites selbst würden so organisiert werden, dass die unteren jeweils die oberen Sprites verdecken, sobald sie sich überlappen.
Auf jeden Fall würde für so etwas ein Spritemultiplexer benötigt.
Ob sowas klappen kann? Keine Ahnung, aber auf alle Fälle ein anderer Weg, und wahrscheinlich etwas Ressourcen sparender, als ein multidirektionales Scolling inkl. Farbram.
Wie abwechslungsreich wäre die Grafik noch bei solchen Limitierungen?
Kann ich noch nicht sagen, weil ich zum einen nicht sicher bin, ob ich die Limitierungen wirklich verstanden habe (siehe nächsten Satz) und zum andere, was es für Auswirkungen bei Bäumen, Häusern etc. haben würde.
In jeder der möglichen 8 Colorramfarben, sind maximal 32 verschiedene Chars möglich.
Wenn ich das richtig verstehe, bleibt die Anzahl unterschiedlicher Chars gleich (256), nur muss man die zu jeweils 32 Chars sortieren, die sich eine ColorRAM-Farbe teilen. Korrekt? Ich glaube, das wäre machbar.
Und kannst du schon abschätzen, wieviele Zeichenmuster die ISO-Darstellung die reine Landschaft (ohne Hindernisse wie Bäumeund Häuser) benötigt?
Ungefähr ja. Überraschend wenige.
Ich stelle hier ein Plateau in Kreuzform, mit allen vorkommenden, abfallenden Flächen, dar. Verdeckungen gibt es im Gelände nicht. Hier haben wir also gerade Flächen, abfallende Flächen in 4 Richtungen, 4 Innenwinkel und 4 Außenecken. Dunkelgrün die doppelten. Man kann diese Formen "auftürmen", um beliebig hohe Berge zu erzeugen.
Hier habe ich die Grafikelemente (Flächen) nochmal von einander getrennt in Originalgröße:
Man kann jetzt selbst zählen, wie viele unterschiedliche Chars man benötigt. Das können um die 10 sein (sogar weniger), aber auch mehr. Es hängt davon ab, ob man manche Formen wegen unterschiedlicher Farbkombinationen aus verschiedenen Bitmustern gebaut benötigt, also ein hier grüner Pixel z.B. 01 oder 10 darstellt. Das könnte optisch gleich sein, vom Bitmuster des Chars dann aber nicht. Um das genau zu sagen, müsste ich noch tiefer einsteigen – bislang habe ich mich nur darum gekümmert, wie sowas grundsätzlich aussehen könnte und ausprobiert, ob der Betrachter die Geländedarstellung auch "versteht".
Und zwar überlege ich, statt mit Chars, mit Sprites zu arbeiten. Diese lassen sich recht einfach in alle Richtungen inkl. Farben bewegen.
Damit es einen 3D Effekt erzeugt, könnte man eine Char Maske, die über den Sprites liegt verwenden, um die Sprites insoweit zu überdecken.
Ich muss zugeben, dass ich mir das Prinzip noch nicht wirklich vorstellen kann. Neben dem Background benötigt man ja auch für das Spielgeschehen Sprites.
Die Sprites selbst würden so organisiert werden, dass die unteren jeweils die oberen Sprites verdecken, sobald sie sich überlappen.
Auf jeden Fall würde für so etwas ein Spritemultiplexer benötigt.
Meines Wissens ist es aber so, dass ein Sprite-Multiplexer ein Sprite erst neu verwenden kann, wenn es zu Ende gemalt wurde (alle 21 Pixelzeilen). Vertikale Überlappungen wären so nicht möglich.
Wenn ich das richtig verstehe, bleibt die Anzahl unterschiedlicher Chars gleich (256), nur muss man die zu jeweils 32 Chars sortieren, die sich eine ColorRAM-Farbe teilen.
Zwar hat man pro Farbe 32 Zeichen, aber davon sind 16 Multicolour und 16 HiRes. Das kann man sich jedoch zunutze machen, indem man z. B. als Hintergrundfarbe grün definiert und die Linien zu anderen nicht grünen Flächen, die aus einer Vordergrundfarbe ($d800) bestehen, mit HiRes zeichnet, was u. U. sogar besser aussehen könnte. Andersherum lassen sich z. B. Zeichen, die nur aus einer einzigen Farbe bestehen, sowohl als Multicolour als auch als HiRes definieren. Man muß da bei der Verteilung eventuell etwas tricksen.
Als schwierigen Farbübergang bei der ISO-Darstellung würde ich zur Zeit den Wechsel von Gelb (Strand) nach Blau (Meer) sehen, da hier zwei potentielle Vordergrundfarben aufeinander treffen. Eventuell müßte man eine von ihnen dann einer Zusatzfarbe zuordnen. Das hängt natürlich gleichzeitig sehr davon ab, wie man andere Objekte wie Häuser oder Bäume gestaltet. Eine Aufgabe für den gewieften Grafiker halt.
Wenn ich das richtig verstehe, bleibt die Anzahl unterschiedlicher Chars gleich (256), nur muss man die zu jeweils 32 Chars sortieren, die sich eine ColorRAM-Farbe teilen.
Ja, genau.
Zwar hat man pro Farbe 32 Zeichen, aber davon sind 16 Multicolour und 16 HiRes.
Beide Varianten sind machber, wie das Programm im Anhang zeigt.
Links HIres/MC-Mix. (Schneller, weil keine "OR #$08"s erforderlich.) Rechts nur MC-Char.
aber fuers Scrollen zahlt es sich definitiv aus
Ja. Hier mal ein Vergleich zwischen der alten Variante mit dediziertem Colormap und der neuen mit kombiniertem Char-/ColorMap (Hires-MC-Mix). Der grüne Berich wird deutlich größer 
Eine Aufgabe für den gewieften Grafiker halt.
Das befürchte ich auch. 
Wenn jetzt einem Char ein feste ColorRAM-Farbe zugeordnet ist, dann würde das doch bedeuten, dass man bei einem Farbwechsel durch "Infizierung" nicht einfach die Farbe wechseln kann, sondern ein doppeltes Set an Chars verwenden muss, oder?
Wenn jetzt einem Char ein feste ColorRAM-Farbe zugeordnet ist, dann würde das doch bedeuten, dass man bei einem Farbwechsel durch "Infizierung" nicht einfach die Farbe wechseln kann, sondern ein doppeltes Set an Chars verwenden muss
Leider ja. Jedes der 256 Zeichen hat eine feste Colorramfarbem, egal ob MC- oder Hires-Char.
Ich habe mal geguckt, wie man den "Kamera-Ausschnitt" anlegen könnte, um ungefähr eine ähnliche Weitsicht horizontal, wie vertikal zu bekommen. Bei folgender Einteilung wären ohne Steigungen in X- und Y-Richtung 9 Fliesen (auf Eck) zu sehen:
Das sind 288 x 144 Pixel, bzw. 36 x 18 Chars. Das würde die Spielfläche nicht zu sehr verkleinern und wäre in alle Richtungen "fair". Gegenüber vollflächigem Scrollen dürfte das ja auch noch einiges an freier Rechenzeit bringen. Zu der unten liegenden Statusanzeige habe ich für Softscrolling eine Char-Reihe freigelassen. Links unten habe ich die Map (64 x 48 Pixel) angedeutet.
Spannend wird noch die Baum-Darstellung. Im Normalfall ist ja nicht fest definiert, was für Flächen "hinter" dem Baum (oder auch Haus) zu sehen sind, also wären auch die Kombinations-Chars nicht starr. Vielleicht muss man einfach definieren, dass Objekte nur da stehen dürfen, wo das Gelände auch im Hintergrund "passt", also z.B. weder Gefälle noch Steigungen zeigt.
Das sind 288 x 144 Pixel, bzw. 36 x 18 Chars.
Die natürliche Bildbreite beim C 64 ist ja 38 Chars, also 304 Pixel. Dann verschenkt man keine Sprites zum Abdecken des Scrollgeflatters. Bei einer links- oder rechtsbündigen Darstellung ein Sprite, bei einer zentierten Darstellung sogar zwei. Die Höhe kann dafür aber pixelgenau gewählt werden, ohne technische Nachteile. Was wäre der passende Y-Wert bei einer Breite von 304?
Links unten habe ich die Map (64 x 48 Pixel) angedeutet.
Wäre eine mittige Radaranzeige oben nicht ästhetischer?
Was wäre der passende Y-Wert bei einer Breite von 304?
Das wäre 152. Aber es muss natürlich nicht hundertprozentig genau sein.
Wäre eine mittige Radaranzeige oben nicht ästhetischer?
So große Statusanzeigen, die künstlich das Spielfeld verkleinern sollen, stehen meistens unten, weil sie sonst in ihrer Massivität auf das Spielfeld "drücken". Und ob die Map mittig oder seitlich platziert werden sollte, hängt vor allem davon ab, was man dort noch so an Anzeigen unterbringen will und wie man das am besten verteilt bekommt. Das ist also nur vorläufig.
So, ich habe da mal was gestestet, so wie ich mir das denke.
So sieht es mit der Charmaske aus, wenn diese die gleiche Farbe wie der Hintergrund hat:
Hier mal die Version, bei der man die Maske sieht:
ZArch64-Test mit Sprites und sichtbarer Maske.prg
Im Prinzip besteht das aus 8 einfarbigen Sprites, also keine MC-Sprites.
Diese werden durch eine Charmaske in "Form" gebracht. In meinem Test habe ich lediglich alle paar Zeilen den Sprites andere Farben zugewiesen. Dadurch könnte man durch einen geschickten Einsatz der Farben per Colorcycling ein vertikales Scrolling ermöglichen. Und je nachdem, wie man die Höhenangaben mit berücksichtigt auch die Tiefeneffekte darstellen.
Horizontal würde ein Scrolling einfach durch das verschieben der Sprites von links nach rechts (oder anderrum) hinbekommen.
Wie gesagt, nur ein Test
Spannend wird noch die Baum-Darstellung. Im Normalfall ist ja nicht fest definiert, was für Flächen "hinter" dem Baum (oder auch Haus) zu sehen sind, also wären auch die Kombinations-Chars nicht starr. Vielleicht muss man einfach definieren, dass Objekte nur da stehen dürfen, wo das Gelände auch im Hintergrund "passt", also z.B. weder Gefälle noch Steigungen zeigt.
Wie elementar sind denn solche Objekte wie Baeume usw fuer das Spielprinzip? Wenn die nur hin und wieder mal rumstehen, so als Deko quasi, dann koennte man das ja vielleicht auch mit Sprites hinbekommen (weils nicht zu viele sind).
Ich habe das nicht zu Ende gedacht, aber was wäre, wenn man hier den Enhanced Color Mode (ECM) verwenden würde? Damit kann man 4 verschiedene Hintergründe haben, ohne dass man das Color-RAM bemühen muss. Gibt zwar nur 64 Zeichen, aber Reduktion als Stilmitel scheint in diesem Spiel ja eh das Credo zu sein.
Hi,
Schaut schon alles ganz gut aus.
Zum Widererkennungswert gehört mMn auch die Form des Flugzeugs. Anbei mal ein Schnellschuss. Wobei ich jetzt von Restriktionen nicht wirklich Dunst habe.
Grundsätzlich gehört wohl auch die schwierige Maussteuerung zum Credo ink. dem Schub zur Höhen(un-)kontrolle gegen die Schwerkraft. Nur ob man das will? Aber zumindest Maussteuerung generell also Option wäre gut.
Lese gespannt weiter mit.
mfg Tobias
Noch ein passender Artikel:
https://www.sockmonsters.com/TheMakingOfZarch.html
QuoteBraben experimented with broader views, but the frame rate suffered. A dynamic rendering system he tried unfortunately shrank the landscape whenever enemy craft appeared, and was dropped
Die hatten wohl damals ähnliche Probleme.
Mit der Maus hätte man auch das "Problem" mit den zwei Feuerknöpfen gelöst. Der Anwenderkreis idürfe aber begrenzt sein. Daher wie gesagt wenn als Option.
was wäre, wenn man hier den Enhanced Color Mode (ECM) verwenden würde? Damit kann man 4 verschiedene Hintergründe haben, ohne dass man das Color-RAM bemühen muss. Gibt zwar nur 64 Zeichen
... und nur fünffarbige Spielfläche (die 4 ECM-Farben + 1 globale, da in deinem Vorschlag konstante Colorramfarbe). Jedes Char auch höchtens zweifarbig mit immer derselben zweiten Farbe, weil ECM nicht mit Multicolor kombinierbar, also immer Hires ist.
Also wenn ich mir das Bild von Retro in #164 ansehe:
- Die Kacheln enthalten immer nur 2 Farben
- Es gibt Diagonalen von 1*1 Char: 2 Zeichen
- Es gibt 2*1 Char: 4 Zeichen.
- Es gibt ein einfarbiges Zeichen: 1 Char
- 7 Zeichen bisher. Die mal 2, damit man freie Wahl zwischen Vorder- und Hintergrundfarbe hat: 14 Zeichen.
Soweit müsste es auch als EMC darstellbar sein. Z.B. die 4 Rot- und Grüntöne als Hintergrundfarben, und wo die sich beissen muss eine Vordergrundfarbe her.
Eine wirklich gute Idee zum Farbram-Scrollen hab ich noch nicht...
Aber wenn ich mir #170 ansehe: Eventuell kann man 2 Zeichen immer die gleiche Farbe geben? Das würde immerhin 1/3 im Vergleich zu einem plumpen Farbram-Kopieren sparen.
was wäre, wenn man hier den Enhanced Color Mode (ECM) verwenden würde? Damit kann man 4 verschiedene Hintergründe haben, ohne dass man das Color-RAM bemühen muss. Gibt zwar nur 64 Zeichen
... und nur fünffarbige Spielfläche (die 4 ECM-Farben + 1 globale, da in deinem Vorschlag konstante Colorramfarbe). Jedes Char auch höchtens zweifarbig mit immer derselben zweiten Farbe, weil ECM nicht mit Multicolor kombinierbar, also immer Hires ist.
Auf dem Mockup-screen sehe ich für die Landschaft nur 5 Farben. Zwei Grünstufen, 2 Rotstufen und Blau für das Wasser. Das schwarz müsste dann ebenfalls durch Grünfläche ersetzt werden. Mit ECM hätte man dann aber Taktzyklen frei für einen potenten Sprite-Multiplexer, damit man sich auch Maskierungen gönnen könnte. Müsste man aber mal Testpixeln zum Sehen, ob man mit ECM zu schnell an die Grenze kommt.
