Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 107 Antworten

letzter Beitrag von steril am

Spieleportierungen - wie würden sie aussehen?

    Was mir beim 264er oft auf und missfällt, ist das rund um die Spielfiguren ( Shapes ?) die Hintergrundgrafik verschwindet.
    Also rund um den Protagonisten ist ein schwarzes Quadrat.
    Ich denke das ist irgendwo ein Faktor der Probleme bereitet.
    Darum ist ein schwarzer Hintergrund optimal.
    Evtl.könnte das mal ein Fachkundiger erklären warum das so ist ?!

    Zitat von Boulderdash64

    Zuerst hieß es, Turrican holt das Maximale aus dem C64 heraus - bis TC II erschien - dann war es TC II, was nicht mehr zu überbieten sei, wie Fachleute sagten... Und DANN hat man sogar TC III umgesetzt - natürlich kann man es nicht mit dem Amiga-Original vergleichen, aber die Grenzen werden immer einen Tick weiter gesteckt...

    Wobei man hinsichtlich Hintergründe und Sprites sagen muss, dass alle drei mit der gleichen Basis arbeiten und wenn man es genau nimmt, gibt es hier nach Turrican 2 keine echte Steigerung mehr. Bzw ich kann mir schon vorstellen, dass in Teildisziplinen noch was zu reißen ist. Von der künstlerischen Seite beispielsweise oder beim Scrolling (Sam's Journey ist ein schönes Beispiel), aber in Kombination von Levelgröße, Einsatz von Animation, Multiplexer, Softsprites und Parallax-Effekten kratzen die Spiele schon an Grenzen.

    Zitat von v3to

    ...kratzen die Spiele schon an Grenzen.

    Kratzen ist gut!! :D - könnte man jetzt auch auslegen, als: Da ist noch mehr drin!! :thumbsup:

    Zitat von Superingo

    Was mir beim 264er oft auf und missfällt, ist das rund um die Spielfiguren ( Shapes ?) die Hintergrundgrafik verschwindet.

    Da der TED keine Sprites hat, sind die Spielfiguren Teil der Hintergrundgrafik.


    Nahezu alle Spiele laufen im Textmodus mit geändertem Zeichensatz. Nehmen wir an, dass die Spielfigur so aussieht:


    AB
    CD
    EF


    Und diese Spielfigur läuft jetzt an einer Stelle vorbei, wo der Level so aussieht:


    HH
    GH
    HH


    (das sei jetzt mal ein Baum mit Astloch oder so). Kopiert man nun einfach die sechs Zeichencodes der Spielfigur an diese Stelle im Video-RAM, entsteht automatisch der Rahmen, weil vom Baum einfach nichts mehr da ist. Dafür braucht es aber auch "nur" sechs Lese- und sechs Schreiboperationen.


    Wenn der Baum durch die Löcher in der Spielfigur durchscheinen soll, muss man zur Laufzeit den Zeichensatz so verändern, dass die Codes A bis F das Aussehen von "Spielfigur vor Baum" annehmen. Zusätzlich zu den oben erwähnten Operationen sind das noch weitere 48 Lese-, 48 Ausmaskierungs-, 48-Einkopier- und 48 Schreiboperationen. Man braucht also Unmengen mehr an Rechenzeit, oder entsprechend vordefinierte Zeichensätze und riesige Lookup-Tabellen.

    Um das zu verhindern, bräuchte man also eine Routine, die quasi jede einzelne Bildspeicherzelle einzeln und direkt beschreibt?! Also permanent den kompletten Videospeicher mit der neuen Grafik beschreiben, oder zumindest den teil, der sich jeweils zum Bild vorher verändert... Ohne Shapes oder sowas zu nutzen...
    Wäre das denn theoretisch machbar? Oder ist das einfach zu langsam in der Umsetzung?
    Mir fehlt das programmiertechnische Fachwissen - daher entschuldigt, meine laienhafte Umschreibung...

    Zitat von steril

    @RKSoft:
    Magst du was zu dem Modus erzählen, für den du die von dir gestalteten Mockups gebaut hast?


    So ganz blicke ich da irgendwie noch nicht durch was der Plus 4 genau kann, und was nicht.
    Zb die 121 Farben, wann wie wo kann ich die überhaupt verwenden?

    Ich verwende den ganz normalen Textmodus. In BASIC z.B. geht dies nicht anders, da der Grafikmodus zu langsam wäre. Das nächste Problem ist, wenn man den Mehrfarbenmodus verwendet, bleiben von den 121 nicht mehr viele übrig. Wie man vom C64er vielleicht kennt, reduziert sich die Farbanzahl im Mehrfarbenmodus (multicolor) um die Hälfte. Dies passiert beim C264er auch. Aber, der C264er kann die 8 übrigen Farben weiterhin mit je 8 Helligkeitsstufen anzeigen lassen. Vorteil für den kleinen 8 Bitter gegenüber dem C64er. Das BASIC 3.5 (auch der 128er mit seinem 7.0 BASIC) hat ja dafür den COLOR Befehl. So bleiben von den 121 Farben dann 7x8+1 = 57 Farben übrig. Weiss, Rot, Türkis, Lila, Grün, Blau und Gelb je 8 Helligkeitsstufen plus Schwarz!
    Beim C64er sind es im MC Modi halt nur noch 8.


    Zitat von tschubakka

    Sorry... aber diese Umsetzung oben von Turrican sieht sowas von schrottig aus... andererseits zeigt es genau den Unterschied auf und eben das, womit ein C16-User seinerzeit leben musste...

    Geb ich dir Recht. Ich habe diesem Mock-up aber auch nur wenig Aufmerksamkeit geschenkt. Ich sollte es vielleicht noch verfeinern. Natürlich könnte ich das Originalsprite plus Grafiktiles für ein Mock-up umsetzen, allerdings könnte man daraus nie ein Spiel basteln, da pro Level ja noch mehr Tiles plus die Bewegungen der Figuren fehlen würde. Ich versuche aber bei meinen Mock-ups immer den Zeichensatz so auszureitzen, daß man auch ein Spiel in BASIC basteln könnte (mal abgesehen von der Geschwindigkeit her).



    @Superingo
    Probleme damit gibt es dazu auch, da man für die fehlenden Sprites Zeichen nehmen muss. Es gibt ja bekanntlich nur 256 Zeichen. Ein Turrican in dem Umfang zu bauen, wie es auf dem C64er ist, wird nahezu unmöglich. Außer, man ändert die Zeichen dynamisch während der Laufzeit (z.B. die Grafiktiles für die Level).


    @TheRealWanderer
    Sieh dir mal mein Mock-up von Pitfall 2 an: https://rksoft.info/2017/05/16…fall-ii-the-lost-caverns/
    Im unteren Bild siehst du ja die kompletten Zeichen, die ich erstellt habe. Wie man bei der Hauptfigur sehen kann, gibt es einmal den kleinen Kerl ohne Hintergrund und einmal mit. Farbüberschneidungen kann man umgehen, wenn man die Farben korrekt einsetzt. Meist verwende ich für Hintergründe einen der 2 Mehrfarben.


    Einen Fehler bei Giana Sisters habe ich gemacht und muss ihn noch beheben: https://rksoft.info/2017/06/30…-the-great-giana-sisters/


    Wenn Giana sich mit dem Busch überschneidet, kommt es zu Farbüberlappungen. Warum? Weil ich bei Giana 4 Farben benutze anstelle von 3 (3 Farben = MC1,MC2 + Hintergrundfarbe). Der Busch hat als Hauptfarbe grün, Giana im unteren Teil Blau.

    Klar, mit geschickter Farbwahl kann man das schon ganz gut hinbekommen, deswegen schrieb ich ja "fast unvermeidbar".
    Dadurch ist aber die Anzahl der Farben eingeschränkt (da wo die Spielfigur oder die NPCs sich mit den Hintergrundgrafiken überschneiden).

    Zitat von Boulderdash64

    Um das zu verhindern, bräuchte man also eine Routine, die quasi jede einzelne Bildspeicherzelle einzeln und direkt beschreibt?! Also permanent den kompletten Videospeicher mit der neuen Grafik beschreiben, oder zumindest den teil, der sich jeweils zum Bild vorher verändert... Ohne Shapes oder sowas zu nutzen...
    Wäre das denn theoretisch machbar? Oder ist das einfach zu langsam in der Umsetzung?
    Mir fehlt das programmiertechnische Fachwissen - daher entschuldigt, meine laienhafte Umschreibung...

    Genau mit "zumindest den Teil".


    Um Mac Bacons Beschreibung oben zu paraphrasieren: die bewegte Figur wird in einen quadratischen oder rechteckigen Rahmen eingepaßt, dieser wird auf ganze Zeichen "gerundet". Um jetzt diese Figur in den Bildschirm zu kopieren, wird zunächst der Hintergrund in einen Pool aus freien (benutzerdefinierten) Zeichen kopiert. Bevor die Zeichen aus dem Pool aber in den Bildschirm kopiert werden, werden deren Definitionen so geändert, daß die bewegte Spielfigur der Hintergrundgrafik überlagert wird. Zuletzt werden die Zeichen dann doch ausgetauscht, und damit erscheint die Spielfigur mit einem Schlag über dem Hintergrund.


    Dazu müssen im beeinflußten Bereich zuerst die jeweiligen Textpositionen des Hintergrunds gelesen werden (ein Load, ein Store), deren Zeichensatzdefinitionen kopiert werden (einiges an Adreßberechnungen + 8 Loads + 8 Stores), die Spielfigur einkopiert werden (ein Load für den den Hintergrund, ein Load für die AND-Maske, ein Load für die OR-Maske, ein Store zurück in den Pool - das ganze mal 8 für jedes Zeichen), zum Schluß das geänderte Zeichen in den Bildschirm (1 Store).


    Gibt für ein Zeichen 2+8+8+(1+1+1+1)x8+1 = 51 Speicherzugriffe, die Verwaltungslogik nicht mitgerechnet.



    Wo das, m.M.n. sehr beeindruckend umgesetzt ist, sieht man im Biathlon-Teil von Winter Olympiade (von Udo Gertz). Da ist der Biathlon-Läufer so ein Objekt aus (glaube ich) 6x6 Zeichen, die über die Bahn und teilweise auch vor den Bäumen, etc. geschoben werden. Bei 6x6 Zeichen hat die Kiste schon einiges zu tun:



    Allerdings ist so ein Objekt eben (wie bereits geschrieben) nun auch Teil der Hintergrundgrafik und erbt damit deren Farbeinschränkungen. Deshalb haben die Sportler im Spiel auch so eine ungesunde Gesichtsfarbe. ;)



    P.S. beim "Zählappell" für die Farben am Objekt kommt man auf 5: weiß, schwarz, braun, grün und das hellblau der Skibahn. Da der Multicolor-Textmodus drei globale Farben und nur eine zeichenabhängige Vordergrundfarbe hat, gibt es tatsächlich einen Attribut-Clash - der ist hier aber gut versteckt: ein Teil der ansonsten grünen Hose ist hellblau.

    Warum wird das Ganze eigentlich über den Zeichensatz gemacht? Weil man den dann am Schnellsten umschalten kann??
    Wäre es nicht einfacher, gewissermaßen Sprites - damit man weiß, was gemeint ist - als Routine zu definieren? Oder die Bildpunkte sozusagen direkt zu beschreiben? Oder ist der 264er zu langsam dafür?

    Zitat von Boulderdash64

    Warum wird das Ganze eigentlich über den Zeichensatz gemacht?

    Außer dem (Multicolor-)Textmodus mit umdefinierten Zeichen ginge sonst nur der Bitmap-Modus. Und damit ist beim C16/C116 der Speicher schlagartig voll: die Bitmap braucht 8 KB + 2 KB für die Attributinfo. Damit hast Du praktisch keinen Platz mehr für den Rest (das Spiel läuft mit 16K) - und das oben gezeigte Hintergrundbild ist nur eins von mehreren. :)

    Zitat von Boulderdash64

    Wäre es nicht einfacher, gewissermaßen Sprites - damit man weiß, was gemeint ist - als Routine zu definieren?

    Du brauchst die Objektdefinition und natürlich eine Routine, um die Objektdefinition in die Hintergrundgrafik einzukopieren.


    Beim C64 macht der VIC-II das in Hardware, on-the-fly, ohne daß die CPU sich darum im Detail kümmern muß (nur die Position + die Objektdefinition incl. Farben müssen gesetzt werden).


    Auf dem C16/C116/+4 oder auch dem VC-20 hat man den Luxus nicht. Hier muß das alles über die CPU abgewickelt werden. Und da ist die schnellste und speicherplatzsparendste Methode die, über den Textmodus zu gehen.

    Zitat von Mike

    Allerdings ist so ein Objekt eben (wie bereits geschrieben) nun auch Teil der Hintergrundgrafik und erbt damit deren Farbeinschränkungen. Deshalb haben die Sportler im Spiel auch so eine ungesunde Gesichtsfarbe.

    Meine Gegentheorie wäre, dass dem Udo irgendwann mal das Monitorkabel kaputt gegangen ist oder er am Grünmonitor gearbeitet hat... anders ist die ebenfalls sehr ungesunde grüne Gesichtsfarbe bei Ghost Town wohl nicht zu erklären...


    Oder er dachte pinkes Gesicht und grüne Haare wäre auch doof.
    Mit dem grünen Gesicht bei Winter Events ist mir neulich auch erst aufgefallen.
    Aber mehr Farben konnte er halt nicht wählen.
    Dafür sind die Animationen einfach toll.
    Was hätte der Mensch mit 64K am 264er noch alles bewegen können...

    nicht übel!!! Ich dachte bis vor kurzem, dass der TI-99 ein Taschenrechner ist... weil ich nen TI-86 hatte und das war so ein kleines, programmierbares handgroßes Teil...