Probier doch wie gesagt mal nur jede 4. Spalte im Farbram zu scrollen
Habe ich auch im Hinterkopf, wenn es nicht anders gehen sollte. Will aber vorher einen universaleren Ansatz testen. Kennst das ja, so viele Ideen und doch so wenig Zeit.
Hallo Besucher, der Thread wurde 26k mal aufgerufen und enthält 203 Antworten
letzter Beitrag von 5ace am
Zarch (Virus) auf dem C64 1:1 machbar?
- DJ SID
- Erledigt
-
-
Ich habe mal ein wenig mit ISO-Darstellung herumexperimentiert. Bitte nagelt mich jetzt nicht auf die Machbarkeit bei den Farben fest – das habe ich noch nicht überprüft. Man kann aber schon ein großes Problem ausmachen: Verdeckungen. Sprites könnten hinter dem Hausdach herfliegen – wahrscheinlich könnte man das nur in den Griff bekommen, wenn das Dach – oder Bäume – selbst auch Sprites wären.
-
Sprites könnten hinter dem Hausdach herfliegen – wahrscheinlich könnte man das nur in den Griff bekommen, wenn das Dach – oder Bäume – selbst auch Sprites wären.
Es würde wohl nur ein einziges Sprite reichen, falls die Map so gestalltet ist, dass in einem eingescrollten Ausschnitt solche in die Höhe ragenden Landschaftsobjekte immer nur untereinander stehen - sich also horizontal nicht überschneiden. (Der Trick ist: Obwohl das erste Sprite eine geringere Priorität als der Hintergrund bekommt und somit unsichtbar wird, werden alle Sprites mit höherer Nummer überdeckt.)
-
• Wenn man bei der Bewegung abfragt, welches Objekt gerade verdeckt, dann braucht man ja auch nur an dieser Stelle ein Maskensprite, und es könnten potentiell verdeckende Objekte dann auch nebeneinander liegen. Wie viel gegnerische Flugis kommen denn dazu?
• Oder die Sprites händisch maskieren, päckchenweise wenigstens.
• Oder die Häuser kleiner machen, um sich die Verdeckung zu ersparen.
-
Sieht voll geil aus.
Und ja, iso ist fürchterlich, aber ich bin manchmal erstaunt wie leichtfertig auch andere Spiele damals mit Verdeckungen umgehen - teilweise werden da einfach Grafikfehler in kauf genommen und es wird halt einfach falsch überdeckt. Klar, will man eigentlich nicht so haben, aber es ist interessant zu sehen dass andere das auch nicht besser zu lösen wussten und vor allem dass einem das teilweise selbst als Spieler gar nicht so wirklich aufgefallen ist.
-
Sieht voll geil aus.
Auf jeden Fall
Eine Idee ist zum Beispiel auf mehr Speedcode bzw. Selbstmodifikation zu setzen.
Nach ein paar Optimierungen wird jetzt auch vertikal und somit diagonal gescrollt. Damit können bisher 22 Zeilen zu je 39 Zeichen in 50 Hz bewegt werden. (Das zweite File ist um das achtfache verzögert, damit es nicht zu chaotisch aussieht.)
Legende zu den Rahmenfarben:
gelb: Selfmod
rot: Kopierschleife
grün: noch verfügbare Rechenzeit
-
Bin am überlegen, wie eine quadratische Spielfläche wirken könnte.
Noch eine Variante. Diesmal mit 24 Zeilen zu 24 Zeichen. Der grüne Bereich, sprich Restrechenzeit ist deutlich größer.
-
Mir kamen gerade die folgenden Gedanken:
Beim Scrollen im Spiel wuerde man ja vermutlich auch Soft-Scrolling verwenden, d.h. in 7 von 8 Frames aendert sich am Bildinhalt ja gar nichts, weil man die Scroll-Registert verwendet, erst im 8. Frame muss umkopiert werden. Wenn man nun die Spiellogik so timen koennte, dass diese sich einfach nicht in jedem Frame updated, sondern nur in jedem 2. Frame, dann koennte man das so legen dass dieser "Umkopier-Frame" immer frei von Spiellogik-Updates ist. Das einzige, was man IMMER updaten muesste, waeren Sprite-Positionen, da diese sonst im Vergleich zum Hintergrund ruckeln (so wie z.B. bei Wizardry).
Nun ist es ja so, dass das Scrolling evtl direkt von der Flugrichtung des Spielers beeinflusst werden soll, demnach also keine solche 100%ige Regelmaessigkeit vorhanden waere (also mit den 7 von 8 Frames). Dies koennte man ausgleichen mit einer "Soft-Camera", die sich eben wirklich immer erst im 8. Frame anpasst, waehrend die Spielfigur bereits in die gewuenschte Richtung fliegt. Damit wuerde das Fliegen sich vielleicht noch ein bisschen "dynamischer" anfuehlen. Oder man verteilt es etwas klueger auf nicht "jeden 8. Frame" sondern jeden 2. Frame, d.h. jeder gerade Frame ist nur fuer Spiellogik-Updates zustaendig, und jeder ungerade Frame besitzt die Moeglichkeit, zu scrollen, sofern notwendig, somit waere die "Kamera" auch maximal nur 1 Frame hinterher, was man als Spieler dann ueberhaupt nicht merken wuerde.
Ich hoffe man versteht einigermassen was ich sagen will
EDIT: Wichtig ist natuerlich dass trotzdem die Softscroll-Register angepasst werden, und zwar in JEDEM Frame
-
Wenn man nun die Spiellogik so timen koennte, dass diese sich einfach nicht in jedem Frame updated, sondern nur in jedem 2. Frame ...
Also Spiellogik nur in 25 Hz, aber Grafik/Animation schon in 50 Hz mit einer Art von Interpolation zwischen den Logikupdates?
jeder gerade Frame ist nur fuer Spiellogik-Updates zustaendig, und jeder ungerade Frame besitzt die Moeglichkeit, zu scrollen
Das meinte ich oben auch mit alternierend.
Auf dem C 64 ist eher 50 Hz der Standart, sowohl für Logik- als auch für Grafikupdates. Auf anderen Platformen wie dem Amiga oder teils auich auf aktuellen Konsolen schau es anders aus. Aber irgendwo muss man hier wohl Kompromisse machen. Die Frage ist nur welche?
-
Naja für die Spiellogik könnten 25 Hz durchaus ausreichen denke ich. Aber es soll halt trotzdem schön aussehen, daher würde ich mit 50 Hz smooth scrollen aber eben aufpassen dass das Umkopieren trotzdem nur in jedem 2. Frame kommen kann, also im Gegenframe zur Spiellogik. Man kann die Spiellogik ja auch aufteilen, z.B. könnte man die Spielfigur auch in jedem Frame steuern lassen können, also Joystick abfragen, aber Gegner und sonstige trotzdem nur alle 2 Frames wirklich updaten.
Boulder Dash ist ja auch ein gutes Beispiel, da passiert ja auch nur alle 4-8 Frames was, aber das Scrolling ist halt trotzdem smooth.
-
Oder die Häuser kleiner machen, um sich die Verdeckung zu ersparen.
Es gibt ja aber auch noch Bäume. Und wenn ich die zu klein mache, dann funktionieren sie nicht mehr als Hindernisse.
Sieht voll geil aus.
Auf jeden Fall
Danke euch beiden. Ich finde, die ISO-Perspektive wirkt dynamischer als die zuvor von mir gewählte. Wenn man sich jetzt noch vorstellt, schnell darüber hinweg zu fliegen und sich dabei der Sprite-Schattenabstand passend zum Untergrund anpasst, dann könnte das schon durchaus attraktiv aussehen.
Noch eine Variante. Diesmal mit 24 Zeilen zu 24 Zeichen.
Finde ich auch gut. Allerdings in Kombination mit meiner ersten Perspektive besser als in Kombination mit ISO. Durch die flachere Perspektive bei ISO hat man ja in der Y-Achse mehr Weitsicht, wodurch eine vertikale Aufteilung weniger stört. Man sollte ein wenig darauf achten, dass die Sicht in alle Richtungen (sofern es technisch geht) etwa gleich ist.
Beim Scrollen im Spiel wuerde man ja vermutlich auch Soft-Scrolling verwenden, d.h. in 7 von 8 Frames aendert sich am Bildinhalt ja gar nichts, weil man die Scroll-Registert verwendet, erst im 8. Frame muss umkopiert werden.
Aber doch wahrscheinlich nur, wenn man so langsam fliegt, dass Softscrolling überhaupt etwas bringt, oder? man müsste also je nach Geschwindigkeit (wenn man sie variabel machen will) das Softscrolling dynamisch machen, also z.B. 1, 2 und 4 Pixel-Sprünge und dann auf Char-Scrolling wechseln.
Nun ist es ja so, dass das Scrolling evtl direkt von der Flugrichtung des Spielers beeinflusst werden soll, demnach also keine solche 100%ige Regelmaessigkeit vorhanden waere (also mit den 7 von 8 Frames). Dies koennte man ausgleichen mit einer "Soft-Camera", die sich eben wirklich immer erst im 8. Frame anpasst, waehrend die Spielfigur bereits in die gewuenschte Richtung fliegt. Damit wuerde das Fliegen sich vielleicht noch ein bisschen "dynamischer" anfuehlen.
"Dynamisch" finde ich immer gut. Ich sagte ja schon, dass ich die "Kamera-Führung" bei RoBB oder auch Sam's Journey sehr interessant finde.
-
Da hast Du natürlich Recht, wenn die Geschwindigkeit variiert muss auch öfter umkopiert werden. In dem Fall würde die Lösung mit alternierenden Frames aber sicherlich auch funktionieren, also jeden 2. Frame maximal das Scrolling updaten (also das Umkopieren), und in den Frames dazwischen die Spiellogik durcharbeiten.
-
Durch die flachere Perspektive bei ISO hat man ja in der Y-Achse mehr Weitsicht, wodurch eine vertikale Aufteilung weniger stört. Man sollte ein wenig darauf achten, dass die Sicht in alle Richtungen (sofern es technisch geht) etwa gleich ist.
Dazu tendiere ich auch eher. Je gestauchter die Sicht in die Tiefe ist, um breiter sollte die gescrollte Spielfläche sein.
Wie gross sollte denn die Map sein? Und ist die Spielwelt flach mit Grenzen oder eine Kugel?
-
Wie gross sollte denn die Map sein? Und ist die Spielwelt flach mit Grenzen oder eine Kugel?
Ich glaube, M. J. hatte sich das Spiel schonmal etwas intensiver angeguckt und kann vielleicht was dazu sagen. Ich bin da ja ein kompletter Neuling und kenne Virus nur aus Videos. Dort ist links oben eine Karte eingeblendet und die sieht nicht gerade klein aus. Deswegen sprach ich ja bei meinem ersten Entwurf von recht großen Tiles – damit man eine große Fläche verwaltet bekommt. Bei der ISO-Darstellung würde ich es präferieren, wenn man die vielleicht sogar dynamisch aus Höhen-Informationen für vielleicht 9 Bildschirm-Flächen generieren und dann cachen könnte. keine Ahnung, ob sowas realistisch ist, oder ob man doch das ganze Spielfeld als Kacheln im Speicher halten muss.
-
Wie gross sollte denn die Map sein? Und ist die Spielwelt flach mit Grenzen oder eine Kugel?
Puh... Das ist jetzt auch schon ca. 15 Jahre her, daß ich Virus disassembliert habe... Ich meine, die Map besteht aus 256x256 Höhenangaben, und gehandhabt wird sie mit Wraparound, d. h. fliegt man links raus, kommt man rechts wieder rein.
Nebenbei: Normalerweise wird ein Scrolling mit Farbram so organisiert, daß im ersten Frame nur die Zeichen in einen zweiten Puffer gescrollt werden (double-buffering). Da hierbei keine Rücksicht auf den Rasterstrahl genommen werden muß, geht dies sehr schnell. Erst im 2. Frame, wenn ein Überlauf stattfindet im Scrollregister, wird auch das Farbram gescrollt und anschließend der Textzeiger auf den jeweils anderen Puffer umgestellt. Bei dieser Methode gibt es aber ein Problem bei einer freien Bewegung in alle Richtungen:
Beispiel:
X = 0 .. 3
Bewegt sich der Spieler nach rechts, sollte jetzt vorausschauend ein Umkopieren des Textspeichers vorgenommen werden, denn bei
X = 7
mit der Geschwindigkeit 1 wäre es bereits zu spät, da nur noch 1 Frame fürs Scrolling verbleibt. Ähnliches ergibt sich bei X = 6 und der Geschwindigkeit 2, X = 5 und der Geschwindigkeit 3 sowie X = 4 und der Geschwindigkeit 4.
Es gilt also, daß zur aktuellen X-Position die X-Geschwindigkeit addiert werden muß. Befindet sich diese dann in der anderen Hälfte (bei einer Bewegung nach rechts 4..7 in Abhängigkeit zur Geschwindigkeit), muß der Textspeicher umkopiert werden. Gleiches gilt für das vertikale Scrollen.
Daraus ergibt sich aber auch ein Konflikt, wenn z. B. zuerst erkannt wird, daß X gescrollt werden muß, aber im nächsten Frame plötzlich auch Y im Scrollregister einen Überlauf erhält, d. h. das Umkopieren für die X-Koordinate überschneidet sich mit dem Umkopieren für die Y-Koordinate. Dafür muß eine Lösung gefunden werden, z. B. indem man das Y-Scrolling um einen Frame verzögert, oder indem man anstelle des Y-Scrollings den Y-Wert für das Sprite ändert.
Ein üblicher Trick, um das Scrollen mit Farbram zu erleichtern und den Platzbedarf für die Tilemap zu reduzieren, ist, als Vordergrundfarbe für das $d800-Ram einfach die unteren 4 Bits des Zeichens zu nehmen. Das beschränkt zwar die Farbwahl für das einzelne Zeichen (es gibt z. B. nur 8 Zeichen mit dunkelblauer Zeichenfarbe im Multicolourmodus), läßt sich aber bei geschickter Organisation des Zeichensatzes kaschieren. Die Kopierschleife des Farbrams bestände dann lediglich darin, den aktuellen Textspeicher in das Farbram zu kopieren.
Alternativ könnte man jedoch auch mal schauen, wieviel Rechenzeit es kostet, den Textspeicher zu kopieren und das Ergebnis gleichzeitig ins Farbram zu übertragen. Sollte dies während eines Frames möglich sein und weiterhin genügend Rechenzeit zur Verfügung stehen für weitere Aufgaben (Musik, Spritemultiplexer etc), könnte man auf das Double-Buffering verzichten. Man soillte jedoch bedenken, daß auf NTSC-Systemen erheblich weniger Zeit pro Frame vorhanden ist. sofern man kein Nur-PAL-Spiel haben möchte.
-
als Vordergrundfarbe für das $d800-Ram einfach die unteren 4 Bits des Zeichens zu nehmen. Das beschränkt zwar die Farbwahl für das einzelne Zeichen (es gibt z. B. nur 8 Zeichen mit dunkelblauer Zeichenfarbe im Multicolourmodus), läßt sich aber bei geschickter Organisation des Zeichensatzes kaschieren. Die Kopierschleife des Farbrams bestände dann lediglich darin, den aktuellen Textspeicher in das Farbram zu kopieren.
Wenn ich das richtig überblicke, sind dann statt 256 noch noch 32 verschiedene MC-Zeichenmüster möglich, weil von 8 Bits nur noch 5 für die Screencodes übrig bleiben. Jedes dieser 32 Zeichen aber in allen möglichen, den ersten 8 Colorramfarben.
den Textspeicher zu kopieren und das Ergebnis gleichzeitig ins Farbram zu übertragen
Bei dieser Variante hätte man dann wohl nur noch 16 Muster, aber in zwei Darstellungsarten (MC und Hires).
@Retrofan Wie abwechslungsreich wäre die Grafik noch bei solchen Limitierungen? Und kannst du schon abschätzen, wieviele Zeichenmuster die ISO-Darstellung die reine Landschaft (ohne Hindernisse wie Bäumeund Häuser) benötigt?
-
Wenn ich das richtig überblicke, sind dann statt 256 noch noch 32 verschiedene MC-Zeichenmüster möglich
Ich muss mich leider korrigieren, nachdem ich ein Testprogramm in Basic (s. Anhang) geschrieben habe.
Der Satz muss so lauten:
In jeder der möglichen 8 Colorramfarben, sind maximal 32 verschiedene Chars möglich.
Aber die Frage bleibt, inwieweit das die grafischen Möglichkeiten einschränken könnte, insbesondere bei Isodarstellung?
-
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.
