- Offizieller Beitrag
Vielleicht nehme ich den orange-farbenen (so habe ich ihn bisher gepixelt) als Default und wir bieten zusätzlich die Möglichkeit an, andere Farbvarianten aussuchen zu können.
Es gibt 300 Antworten in diesem Thema, welches 62.593 mal aufgerufen wurde. Der letzte Beitrag (
Vielleicht nehme ich den orange-farbenen (so habe ich ihn bisher gepixelt) als Default und wir bieten zusätzlich die Möglichkeit an, andere Farbvarianten aussuchen zu können.
Mal eine Frage an die Interna-Auskenner: Ist es korrekt, dass in BD ein 640 x 352 Pixel großer Screen verwaltet wird, von dem man nur 1/4 als Ausschnitt sieht oder wird der Cave platzsparend, z.B. als 1 Byte je Tile, verwaltet und nur der Bereich gerendert, den man für den Ausschnitt benötigt?
Ist es korrekt, dass in BD ein 640 x 352 Pixel großer Screen verwaltet wird, von dem man nur 1/4 als Ausschnitt sieht oder wird der Cave platzsparend, z.B. als 1 Byte je Tile, verwaltet und nur der Bereich gerendert, den man für den Ausschnitt benötigt?
Mehr oder weniger beides. Zunächst mal gibt es natürlich das Cave-Array, wo der eigentlich Cavescan die Spielphysik berechnet. Jede Bewegung wird direkt in dieses Array geschrieben und zusätzlich noch direkt das 2x2-Tile in einen virtuellen Screen geschrieben, der das ganze Cave abdeckt. Die Scrollroutine pickt sich dann jeweils den gerade sichtbaren Bereich heraus und kopiert den in den Bildschirmspeicher, wie er vom VIC dann angezeigt wird. Ich glaube sogar mit Doublebuffer, wenn ich es richtig in Erinnerung habe.
Meine XDC-Engine geht da etwas anders vor. Beim Cavescan selbst werden da keine Framebuffer mehr beschrieben. Das mache ich alles im Interrupt, wo die 2x2-Tiles des sichtbaren Ausschnitts in Echtzeit per Speedcode zusammen gesetzt werden. Mein Ansatz läßt ein gleichmäßigeres Timing zu, aber mehr Zeit zum Farb-RAM Beschreiben bleibt da auch nicht übrig.
Evtl. ließe sich die Originalmethode mit VSP beschleunigen.
Hi
ich war immer der Meinung das die Cave, die man betritt komplett im Speicher steht. Wie sonst können die Schmetterlinge und andere Gegner sich frei bewegen in der Cave.
Kann mich aber irren. Aber da ich früher sehr viel Caves gebaut habe mit dem Construction Kit, war ich immer der Meinung das man die Cave komplett in einen bestimmten Speicherbereichen liegen müsste.
Es gab schließlich die Option die komplette Cave auf die Bildschirm zu sehen ob alles passt und sogar antesten.
Aber wie gesagt, ich kann mich auch irren.
Bitte melde dich an, um diesen Link zu sehen.
Ich sehe nicht, dass Bitte melde dich an, um diesen Link zu sehen. behauptet hat, es waere nicht komplett im Speicher...
ich war immer der Meinung das die Cave, die man betritt komplett im Speicher steht.
Natürlich muss die ganze Cave komplett im Speicher stehen – wegen der vielen Wechselwirkungen im ganzen Level. Die Frage war eher, ob sie auch grafisch komplett im Speicher steht oder nur von der Spiel-Logik her.
Jede Bewegung wird direkt in dieses Array geschrieben und zusätzlich noch direkt das 2x2-Tile in einen virtuellen Screen geschrieben, der das ganze Cave abdeckt.
Für mich liegt an dieser Stelle eine Menge Einspar-Potential. Würde es nicht reichen, sich nur die Zeilen oder Spalten aus dem Array zu holen, die man für den nächsten Frame zum Scrollen benötigt? Mir ist langsam klar, dass das verwendete Verfahren für den Atari total simpel ist – aber für den C64 bedeutet es sehr viel Arbeit, einen Screen (den wirklichen Screen und nicht nur die Spiel-Logik) zu verwalten, der 4 mal so groß ist, wie der Bildausschnitt.
Würde es nicht reichen, sich nur die Zeilen oder Spalten aus dem Array zu holen, die man für den nächsten Frame zum Scrollen benötigt?
Genau das macht meine Engine ja auch. Sollte man aber auch nicht unterschätzen. Die 2x2-Tiles in Echtzeit zusammen zu setzen ist doch schon eine andere Nummer als einfach nur Zeilen zu kopieren. Das sind immerhin 220 sichtbare Tiles (20x11). Da bleibt im Endeffekt auch nicht mehr CPU-Zeit übrig. Beschränkt man sich auf die Original-Elemente, hätte man noch zwei Bits im Array frei, die man dafür nutzen könnte, der Scrollroutine mitzuteilen, was neu gezeichnet werden muß. Halte ich aber für gefährlich, denn wenn sich mal wirklich viel bewegt, kann es mit den zusätzlichen Bitgehangel in Ausnahmefällen sogar langsamer werden, was keine Option ist, wenn man CPU-Zeit für individuelle Farben frei machen will.
Mit dem virtuellen Screen gibt es das Problem so aber nicht, denn da wird nur direkt bei erfolgten Bewegungen drin geschrieben, und genau da könnte eine VSP-Scroll-Routine ansetzen und müßte immer nur eine Zeile und/oder Spalte da raus kopieren. So könnte genug Zeit für individuelle Farben frei werden. Die Statuszeile könnte man als Sprite-Overlay umsetzen, um mehr Spielraum für die VSP-Routine zu geben. Evtl. im Rahmen platziert.
VSP-Scroll-Routine... bei dem Stichwort werde ich immer nervös, wenn sowas ein Coder vorschlägt, auch wenn LFT eine stabile Methode vorgestellt hat. Idr läuft es sonst nur auf jedem dritten C64 ohne Absturz.
Man sollte auch nicht vergessen, daß wir hier nicht einfach einen Hintergrund scrollen, wie das bei vielen Spielen passiert. Jedes einzelne Teil kann sich zum nächsten Frame verändern. Dadurch würde es sich selbst mit VSP ziemlich anspruchsvoll gestalten, denn man muß ja nicht nur beim Scrollen im Screen- und Farb-RAM schreiben, sondern auch bei jeder Bewegung im Cave. Die Schreibzugriffe während des Cavescan würden im Vergleich zum Original schonmal wegen der Farbe verdoppelt, und im sichtbaren Bereich sogar vervierfacht, wenn die Scrollroutine nicht mehr jedesmal den ganzen Bildschirm beschreiben soll. Animierte Farben, wie beim Glühwürmchen in der Beispielanimation weiter oben, wären dabei noch nichtmal berücksichtigt.
Wie auch immer die Anzeigeroutine umgesetzt wird. Ich halte es immer noch für ein enormes Unterfangen, und Respekt, wem das gelingt.
Wie gesagt, ich halte von VSP nichts, weil es in Spielen zumindest auf dem meisten C64 nicht stabil läuft. Es erscheint mir aber auch absurd, bei der bestehenden Qualität von 8-Wege-Scrollroutinen inkl Colourram ausgerechnet bei Boulder Dash auf solch eine Technik zurückzugreifen.
Ich schaffe mit meinerm Code einen kompletten Screen-Update inklusive Coloram in ungefähr einen halben Frame ...
Wenn ich LogicDeLuxe richtig verstanden habe, können sich im schlimmsten Fall für den sichtbaren Ausschnitt alle Tiles ändern.
Deshalb muß der Ausschnitt immer komplett neu aufgebaut werden, dabei ist es egal ob dieser scrollt oder nicht.
Das bedeutet für VSP, je mehr sich im sichtbaren Ausschnitt ändert desto weniger Wirkung, das gleiche gilt auch für den Atari.
Es gibt da aber noch was........
Retrofan:
KC85
Bitte melde dich an, um dieses Medienelement zu sehen.
DTV
Bitte melde dich an, um diesen Link zu sehen.
word word
Das bedeutet für VSP, je mehr sich im sichtbaren Ausschnitt ändert desto weniger Wirkung, das gleiche gilt auch für den Atari.
Der Atari hat da in Form der Displaylist eine prima Hardwarebeschleunigung um den virtuellen Screen umzusetzen. Das ist dann eher mit dem VDC am C128 vergleichbar, welcher ebenfalls virtuelle Screens unterstützt. Im Prinzip muß man dem Videochip nur mitteilen, wo bei den Zeilen jeweils der gerade sichtbare Teil im Speicher anfägt, und die CPU muß da nichts weiter machen. Beim VDC ist das sogar lediglich ein Offset-Register, mit dem man Einfluß auf die Länge der virtuellen Zeilen nehmen kann. Das ist kein Vergleich zum Aufwand, der da am C64 getrieben wird.
Vielleicht wäre ja mal ein VDC-Boulder-Dash am C128 eine Möglichkeit, mehr Farbe ins Spiel zu bringen.
Beim verschieben des Ausschnitt ist der Atari im Vorteil, kenne ich vom Amiga.
Was ich meinte ist das verschieben der Tiles, dann müssen auch auf dem Atari viele Daten kopiert werden.
Beim C64 ist es im Prinzip egal wie viele Tiles bewegt werden, da immer kopiert wird.
Beim C64 ist es im Prinzip egal wie viele Tiles bewegt werden, da immer kopiert wird.
Egal ist es nicht. Es muß ja auch erst in den virtuellen Screen geschrieben werden, und das passiert nur bei Tiles, die sich bewegen oder auf der Stelle verändern. Wenn viel im Cave los ist, wird es schon merklich langsamer, insbesondere bei BD1, weil dort die Geschwindigkeit lediglich über eine Schleife reguliert wird, die eine vorgegeben Anzahl Zyklen verbrät. Ab BD2 hat man das etwas intelligenter gemacht, indem man Frames zählt, bevor der nächste Cavescan startet.
Bitte melde dich an, um diesen Link zu sehen. wow, vielen Dank fuer das Posten dieses Videos. Ich kenne einen DOS-Clone von Boulder Dash namens "Digger" (nicht zu verwechseln mit einem anderen DOS-Spiel das genauso heisst aber eher ein Mr. Do Clone ist), und die Grafik ist quasi identisch mit der KC85-Version! Ich ging eigentlich immer davon aus, dass es sich bei "Digger" um einen eigenen Grafikstil handelt, und nicht dass dieser auf dem eines Heimcomputers basiert. Wieder was gelernt ![]()
Egal ist es nicht. Es muß ja auch erst in den virtuellen Screen geschrieben werden, und das passiert nur bei Tiles, die sich bewegen oder auf der Stelle verändern. Wenn viel im Cave los ist, wird es schon merklich langsamer, insbesondere bei BD1, weil dort die Geschwindigkeit lediglich über eine Schleife reguliert wird, die eine vorgegeben Anzahl Zyklen verbrät. Ab BD2 hat man das etwas intelligenter gemacht, indem man Frames zählt, bevor der nächste Cavescan startet.
Mit der original Engine stimmt das natürlich. Ich dachte da an deiner Engine, die ohne virtuellen Screen auskommt und direkt aus dem Cave-Array kopiert.
Komischerweise hat das bisher fast keiner auf dem Radar und peiselulli lässt die Katze einfach nicht aus dem Sack.
Vorab, ich mag VSP auch nicht sonderlich bei Spielen, weil es eben nicht auf jedem Vanilla C64 läuft. Es gibt aber noch eine Alternative zu VSP, die hier von peiselulli schon erwähnt wurde und auch einige Vorteile hat.
Aus reiner Neugier bin ich der Sache mal nachgegangen, was und wie dieser Farbram-Buffer funktioniert. Und genau hinter diesen Farbram-Buffer steckt viel mehr als man denkt. Wichtig, laut Test mit Vice soll das ganze VSP sicher sein, es wäre echt schade sollte dies nicht stimmen. Da die ganzen Infos mehr oder weniger verteilt sind, werde ich das ganze noch mal ausführlich erläutert. Mit den Ziel es möglich einfach und verständlich zu halten.
Achtung!
Es ist immer heikel, wenn man so was wie VSP/FLD u.s.w. noch nie selbst programmiert hat, deshalb alles ohne Gewähr. Im großen und ganzen sollte aber alles stimmen. Wer will kann sich aber mit den Link von peiselulli aus posting 79 und per Suche im Forum, das ganze selber nochmal durchlesen.
Aus dem VIC-II Manual.
3.14.5. Verdoppelte Textzeilen
Normalerweise ist die Darstellung einer Textzeile nach 8 Rasterzeilen zu Ende, denn dann ist RC=7 und in Zyklus 58 der letzten Zeile geht der Sequenzer in den Idle-Zustand (siehe Abschnitt 3.7.2.).
Erzeugt man jetzt aber einen Bad-Line-Zustand zwischen Zyklus 54-57 der letzten Zeile, so bleibt der Sequenzer im Display-Zustand und der RC wird nochmals erhöht (und läuft damit auf Null über).
Dann beginnt der VIC in der nächsten Zeile nochmal mit der Darstellung der vorigen Textzeile. Da keine neuen Videomatrixdaten gelesen wurden, wird die vorige Textzeile einfach doppelt dargestellt.
Hier mein Versuch das Prinzip zu erklären.
Standard-Screen eines C64.
1. AAAAAAAA
2. BBBBBBBB
3. CCCCCCCC
4. DDDDDDDD
5. EEEEEEEE
6. FFFFFFFF
7. GGGGGGGG
8. HHHHHHHH
Zeilenbuffer:
Mit den wiederholen der Textzeile gibt man alle ungeraden Zeilen doppelt aus. Dadurch werden alle geraden Zeilen vom Bildschirm und Farbram verdeckt. Die verdeckten Zeilen dienen dann als Buffer für das umkopieren.
1. AAAAAAAA ; Verdoppeln
2. AAAAAAAA ; Verdeckte Zeile -> Buffer
3. BBBBBBBB
4. BBBBBBBB
5. CCCCCCCC
6. CCCCCCCC
7. DDDDDDDD
8. DDDDDDDD
Grafikzeichen:
Damit die verdeckten Zeilen scheinbar wieder eigene Zeichen bekommen, wird nach jeder Zeile zwischen zwei Zeichensätzen hin und her gewechselt. Wobei es sich aber um einen geteilten Zeichensatz handelt, der sich aus Ober und Unterseite der selben Zeichen zusammensetzt.
1. AAAAAAAA ; Zeichensatz oben
2. BBBBBBBB ; Zeichensatz unten
3. CCCCCCCC
4. DDDDDDDD
5. EEEEEEEE
6. FFFFFFFF
7. GGGGGGGG
8. HHHHHHHH
Farbram-Doublebuffer:
Damit wäre das Prinzip vom Doublebuffer für das Farbram mehr oder weniger durch und das ganze könnte hier beendet werden. Es gibt aber noch so viele Feinheiten zu den Screen und beim Scrolling, das es sich lohnt auch darauf einzugehen, deshalb ist der Text auch deutlich länger als geplant.
Also weiter:
Wenn man die Zeilen Verdoppeln/Buffer vertauscht, erhält man folgende Screens.
Screen - A
1. XXXXXXXX ; Verdoppeln
2. xxxxxxxx ; Buffer
3. XXXXXXXX ; Verdoppeln
4. xxxxxxxx ; Buffer
5. XXXXXXXX ; Verdoppeln
6. xxxxxxxx ; Buffer
7. XXXXXXXX ; Verdoppeln
8. xxxxxxxx ; Buffer
Screen - B
1. xxxxxxxx ; Buffer
2. XXXXXXXX ; Verdoppeln
3. xxxxxxxx ; Buffer
4. XXXXXXXX ; Verdoppeln
5. xxxxxxxx ; Buffer
6. XXXXXXXX ; Verdoppeln
7. xxxxxxxx ; Buffer
8. XXXXXXXX ; Verdoppeln
Erste Zeile:
Da man nur beim verdoppeln einer Zeile einen Buffer hat, ist bei Screen - B die erste Zeile ohne Buffer. Damit diese Zeile auch einen Buffer erhält, könnte man diese einfach mit einen illegalen Grafikmode verdecken.
Dann wäre da noch die letzte Zeile im Screen - B, da es keine weitere Zeile gibt braucht diese auch nicht verdoppelt werden.
Jetzt kann man ohne Probleme nach oben oder unten scrollen. Die neuen Grafikdaten werden je nach Richtung nur im Screen A oder B kopiert.
Screen - A
0. XXXXXXXX ; I-Mode / Verdoppeln
1. xxxxxxxx ; Buffer
2. XXXXXXXX ; Verdoppeln
3. xxxxxxxx ; Buffer
4. XXXXXXXX ; Verdoppeln
5. xxxxxxxx ; Buffer
6. XXXXXXXX ; Verdoppeln
7. xxxxxxxx ; Buffer
Screen - B
0. xxxxxxxx ; I-Mode / Buffer
1. XXXXXXXX ; Verdoppeln
2. xxxxxxxx ; Buffer
3. XXXXXXXX ; Verdoppeln
4. xxxxxxxx ; Buffer
5. XXXXXXXX ; Verdoppeln
6. xxxxxxxx ; Buffer
7. XXXXXXXX ; ----------
Richtung:
Leider fehlt für die andere Richtung noch etwas. Da der Buffer zeilenweise arbeitet, hat man kein Farbbuffer für links/rechts scrolling.
VIC-II Manual.
3.14.2. FLD
Beim Aufbau der Grafik nach Textzeilen orientiert sich der VIC ausschließlich am Auftreten der Bad Lines: Eine Bad Line gibt das "Startsignal" für die Darstellung einer Textzeile.
Durch geeignetes Ändern von YSCROLL (in Register $d011) kann man den Bad-Line-Zustand unterdrücken (siehe 3.5.) und beliebig verzögern.
Man kann so genau steuern, in welchen Rasterzeilen Bad Lines auftreten sollen und damit, ab welchen Rasterzeilen der VIC jeweils eine Textzeile darstellen soll.
So läßt sich der Abstand zwischen zwei Textzeilen beliebig vergrößern, wenn man die nächste Bad Line nur lange genug zurückhält.
Dieser Effekt wird als "Flexible Line Distance" (FLD) bezeichnet. Läßt man z.B. im ganzen Bildschirm nur drei Bad Lines bei den Rasterzeilen $50, $78 und $a0 zu, so stellt der VIC auch nur drei Textzeilen jeweils an diesen Positionen dar.
Dazwischen ist der Sequenzer im Idle-Zustand. Verzögert man nur das Auftreten der ersten Bad Line, kann man die komplette Grafikdarstellung um große Distanzen nach unten scrollen, ohne auch nur ein Byte im Grafikspeicher zu verschieben.
Spaltenbuffer:
Für links/rechts verschiebt man per FLD den Bildschirm mit den ungraden Zeilenbuffer eine Zeile nach unten. Durch das hin und her verschieben der Zeile erhält man für die sichtbare Zeile den Buffer.
Screen - A
0. -------- ; I-Mode / FLD
1. XXXXXXXX ; Verdoppeln / sichtbar
2. xxxxxxxx ; Buffer
Screen - B
0. xxxxxxxx ; I-Mode / Buffer
1. XXXXXXXX ; Verdoppeln / sichtbar
Richtungswechsel:
Auch hier gibt es wieder ein paar Dinge zu beachten. Es ist wichtig das Screen - B aktive ist, bevor man von vertikal/horizontal in die andere Richtung scrollt. Nur bei Screen - B fängt das Zeilenpaar in Zeile 1 an. Wenn man jetzt Screen - A nach unten bewegt, verschiebt man das Zeilenpaar auf die selbe Höhe und sieht gleichzeitig die Bewegung nicht.
Für Boulder-Dash reicht das aus, da man hier immer um ein ganzes Tile und nicht Zeilen/Spaltenweise scrollen muss, damit wären wir ein zweites mal durch. Damit das ganze komplett ist, kommt hier noch der Rest.
Wenn man nicht darauf verzichten kann das auch Screen - A aktive ist, braucht man eben noch einen weiteren Trick.
3.14.4. Linecrunch
Die Manipulation von YSCROLL bietet noch mehr Möglichkeiten, auf Bad Lines Einfluß zu nehmen. Man kann auch eine Bad Line vor ihrer korrekten Beendigung abbrechen, indem man durch Änderung an YSCROLL den Bad-Line-Zustand innerhalb einer angefangenen Bad Line vor Zyklus 14 wieder wegnimmt. Das hat mehrere Konsequenzen:
- Der Grafikdaten-Sequenzer geht in den Display-Zustand, es wird also Grafik dargestellt.
- Der RC wird nicht zurückgesetzt. Wenn man gleich die erste Bad Line eines Bilds auf diese Art abbricht, steht der RC noch von der letzten Zeile des vorigen Bildes auf 7.
- In Zyklus 58 der Zeile ist RC immer noch 7, darum geht der Sequenzer in den Idle-Zustand und VCBASE wird mit VC geladen.
Da der Sequenzer aber innerhalb der Zeile im Display-Zustand war, wurde VC nach jedem g-Zugriff erhöht, also ist VCBASE jetzt effektiv um 40 erhöht worden. Der RC macht keinen Überlauf, er bleibt auf 7.
Mit diesem Verfahren hat man also die Darstellung einer Textzeile auf deren letzte Rasterzeile reduziert, denn weil VCBASE um 40 erhöht wird, geht der VIC anschließend zur nächsten Zeile über.
Daher wird dieser Effekt als "Linecrunch" ; bezeichnet: Man kann damit einzelne Textzeilen "wegcrunchen".
Wenn man nun in jeder Rasterzeile so vorgeht, so steht der RC immer auf 7 und es finden keine c-Zugriffe statt, aber VCBASE wird in jeder Zeile um 40 erhöht.
Dies führt irgendwann dazu, daß VCBASE die 1000-Byte-Grenze der Videomatrix überschreitet und der VIC auch die letzten, normalerweise unsichtbaren 24 Byte der Matrix darstellt (in denen u.a. die Spritedatenzeiger abgelegt sind) und bei Erreichen von 1024 wieder bei Null anfängt.
Dadurch, daß man ganze Textzeilen auf je eine Rasterzeile crunchen kann, hat man eine Möglichkeit, den Bildschirminhalt schnell um große Distanzen nach oben zu scrollen, ohne den Grafikspeicher zu ändern, ähnlich wie man ihn mit FLD nach unten scrollen kann. Der einzige störende Nebeneffekt dabei ist, daß sich die weggecrunchten Zeilen am oberen Bildschirmrand ansammeln, was unschön aussieht.
Hier kann man aber durch Anwendung eines der ungültigen Grafikmodi recht praktisch im Bereich dieser Zeilen auf schwarz schalten.
Screen-B:
Um es etwas kürzer zuhalten, mit Linecrunching kann man ganze Zeilen nach oben schieben. Damit können wir jetzt die Zeilenpaare von Screen - B auf die richtige Höhe schieben.
Durch das verschieben ist es nötig die letzte Zeile wieder doppelt auszugeben, damit werden dann auch gleichzeitig die unerwünschten Spritepointer verdeckt.
Screen - A
0. XXXXXXXX ; I-Mode / Verdoppeln
1. xxxxxxxx ; Buffer / sichtbar
Screen - B
-. xxxxxxxx ; Buffer
0. XXXXXXXX ; I-Mode / Verdoppeln
1. -------- ; sichtbar
Zum Schluss:
Aufgrund der Verdoppelung hat man ein paar kleine Einschränkungen. Die Grafik wird immer aus Tiles aufgebaut, selbst bei 1x2 Zeichengröße und nur für das obere Zeichen hat man eine Farbe aus dem Farbram.
Vorteile:
- Den Buffer erhält man gratis und kostet kein Speicher.
- In den nicht sichtbaren Zeilen, kann man ohne flackern schreiben.
- Je nach Scrollspeed/Tilegröße, sind nur wenige Bytes zu kopieren.
- Es können mehr Zeichen als üblich verwendet werden.
Nachteile:
- Sprites sind zwar möglich, aber mit den üblichen Aufwand verbunden.
- Je größer die Tiles desto weniger Farben aus dem Farbram.
- Das verdoppeln der Zeile und Linecrunching erfordert genaues Timing.
- Der Zeichensatz verbraucht mehr Speicher.
Letzte Worte zum Tile-Base Grafikmode.
Das ganze scheint perfekt für BD zu sein. Da mir der Grafik-style von Retrofan sehr gut gefällt, könnte damit auch der Weg für ein BD64-Deluxe frei sein. Wie viel Arbeit und Zeit das alles kostet ist schwer abzuschätzen.
Links:
Bitte melde dich an, um diesen Link zu sehen.
Bitte melde dich an, um diesen Link zu sehen.
Bitte melde dich an, um diesen Link zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
Leider fehlt für die andere Richtung noch etwas. Da der Buffer zeilenweise arbeitet, hat man kein Farbbuffer für links/rechts scrolling.
Da sehe ich jetzt gar kein Problem. Die Idee ist richtig gut. Man erhält praktisch Zeichen, die 16 Rasterzeilen hoch sind. Am Prinzip vom virtuellen Screen kann man festhalten, denn auch der würde deutlich entlastet werden. Er wäre ja nur noch 80x22 statt 80x44 groß. Auch der Teil der Engine, der in den virtuellen Screen schreibt, kann dabei die Schreibzugriffe halbieren.
- Der Zeichensatz verbraucht mehr Speicher.
Sehe ich nicht. Der wird doch nur anders aufgeteilt, aber dabei nicht größer. Aus einem ganzen Zeichensatz kann man zwei halbe machen, und z.B. jeweils die zweite Hälfte für Code nutzen.