C65 Next Generation MEGA65


  • tulan
  • 126677 Aufrufe 1862 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Hmm also das die Kiste 1080p ausgibt bedeutet ja noch nicht das such so viele Pixel berechnet werden.
    Beim TC64 zum Beispiel werden ja auch höhere Auflösungen über VGA ausgegeben.
    Aber darum laufen die Programme trotzdem in der ursprünglichen Auflösung also zum Beispiel 320x200 oder was es so gibt...
    Dies ist der Anfang einer langen Reise...
    leicht und atemlos.
    Dies ist der Weg aus dem Tal der Tränen
    Nimm meine Hand und lass sie nie wieder los

    B.O.
  • Superingo schrieb:

    Hmm also das die Kiste 1080p ausgibt bedeutet ja noch nicht das such so viele Pixel berechnet werden.
    Wenn die Auflösung in den Specs angegeben wird, gehe ich davon aus, dass ich sie als Modus nutzen kann. Zumal die Sichtgeräte ja auch selbsttätig niedrigere Auflösungen skalieren können.
  • Naja durch den DMagic mit integrierten Blitter geht mit dem C65 schon was, ich denke einiges mehr als mit einem C64, aber an einen Amiga reicht das nicht ran. Der native VIC III kann 128k RAM adressieren und hat 32K Color RAM, damit ist schon einiges mehr machbar als mit dem C64. Der Mega65 erhält noch weitere Spielereien, mehr Farben, höhere Auflösung, buntere Sprites... Was mich persönlich am meisten reizt ist der native C65 Modus. Ob mir das ausreicht einen Mega65 zuzulegen hängt vom Preis des Geräts ab.
    +60K Speichererweiterung für den C64, TapeDevil Toolcollection fürs TapeCart
    C64 [Assy 250466, 1541U2+, MixSiD, Keyman64, Overlay64, Reprom64, AC/64]; U64 [2xARMSID]
    A500+ [Rev 8A1, A1k-TK-SRAM-IDE], A600 [Rev 1.3, ACA620], A1200 [Rev. 2B, ACA1233n]
  • für mich ist der c65 einfach ein neuer homecomputer. mir persönlich ist es egal wieviel retro darin ist.
    ich versteh auch die diskussion um das diskettenlaufwerk nicht. wenn das ding dadurch 20 euro
    teurer wird: na und !?! haben ist sowieso wichtiger als brauchen.
    ich denke billig zu haben wird er sowieso nicht sein.

    letztendlich ist es doch geil das da überhaupt so viel kommt. wenn ich mir das design vom spectrum next anseh,
    bin ich kurz vor nem organismus :D

    so wie schon gesagt wurde, mit 50mhz kann man auch mal interessante dinge in basic machen.
    ist bestimmt nicht für jeden interessant, aber da hat jeder andere vorstellungen. mir machen macś und pcś
    einfach keinen spass. die taugen besten falls als internetkonsole oder als staubsauger. 8)
  • Markaine schrieb:

    durch den DMagic mit integrierten Blitter geht mit dem C65 schon was, ich denke einiges mehr als mit einem C64, aber an einen Amiga reicht das nicht ran.
    Und so macht es ja auch Sinn – aber der Mega65 geht da halt deutlich weiter, bei Auflösung und auch MHz – und da finde ich, wurde über das Ziel hinaus geschossen. Letztlich muss aber jeder selbst entscheiden, ob das eine Plattform ist, die er von den Specs her mag. Ich glaube nicht, dass mein Einwand hier auf fruchtbaren Boden fällt. Und selbst wenn die grafischen Fähigkeiten bei denen des C65 blieben, wäre mir das (für eigene Grafiken) schon zu viel. Wenn mir z.B. 320 x 256 Pixel @ 32 Farben ohne weitere Beschränkungen Spaß machen würden, würde ich ja auf dem Amiga oder Falcon pixeln. Ehe ich aber das tun würde, würde ich eher was für den Pico-8 machen – da ist einfach mehr Herausforderung, die mir Spaß macht.
  • Retrofan schrieb:

    Man hatte die Wahl zwischen vielen Farben (256, langsam) oder weniger Farben (= weniger Bitplanes = 4 Farben = schneller).
    Kleine Korrektur: Man hatte die Wahl zwischen vielen Farben (sehr, sehr langsam) und weniger Farben (sehr langsam). Zum Vergleich: Der Apple //gs hatte für Spiele eine Auflösung von 320x200x16 (vergleichbar mit Amiga und Atari) und einen 2,8 Mhz 65816 16 Bit-Prozessor. "Metal Dust" läuft auf einem C64 mit C64-Auflösungen, aber einem 20(!) Mhz 65816. Der C65 hingegen bekam nur eine 8 Bit-CPU mit 3,5 Mhz zugebilligt. Damit hätte man ein paar nette Standbilder hinbekommen, aber keine flüssige Spielgraphik, die die erweiterten Fähigkeiten ausnutzen kann. Hinzukommt noch der für höhere Auflösungen extrem knappe Speicher von 128 kb und das lästige Banking. Anders gesagt: Für die angestrebte graphische Auflösung war der Rechner viel zu unterdimensioniert. Wenn daher jetzt ein Mega65 erscheint mit 50 Mhz CPU, Riesenspeicher und vielen bunten Sprites, hat das mit dem Original von damals[tm] wirklich wenig zu tun. Das heißt nicht, daß das Projekt deswegen schlecht wäre, aber man soll sich halt auch nichts vormachen. Es ist eher unwahrscheinlich, daß jemals echte C65-Software (außerhalb von Basicprogrammen) dafür erscheinen wird.
  • Markaine schrieb:

    Was mich persönlich am meisten reizt ist der native C65 Modus. Ob mir das ausreicht einen Mega65 zuzulegen hängt vom Preis des Geräts ab.
    Aber wenn DER richtig genutzt werden soll, zumindest für Demos und Spiele, dann müsste man ja auch das zugrundeliegende System wirklich ordentlich debuggen und von Fehlern bereinigen, DAMIT überhaupt was drauf laufen KANN - oder irre ich mich da?
    VIC20 / C64 / C128 / C16 / C+4 / Amiga 500 / Amiga 2000 / Amiga 1200 / Amiga 4000 / Amiga 4000 PPC / CD32 / PlayStation / PS2 / PS3 / PS4 / N64 / Wii / WiiU / Switch - hab ich! :D
  • Als Übersicht gar nicht so schlecht: Wikipedia C65
    Specs des C65 (Commodore), sehr ausführlich: C64DX (=C65) SYSTEM SPECIFICATION

    Retrofan schrieb:

    aber der Mega65 geht da halt deutlich weiter, bei Auflösung und auch MHz – und da finde ich, wurde über das Ziel hinaus geschossen. .
    Der Mega65 bekommt einen C65 nativen Mode (3,5 MHz, VICIII Modes wie das Original usw.) und genau das übt einen Reiz auf mich aus, der nie erschienene letzte 8bit Rechner von Commodore, vielleicht mal verfügbar in Form des Mega65. Ich finde das einfach superspannend. Der Mega65 Mode mit all dem Firlefanz (50 MHz, hohe Auflösungen, erweiterte Spritefunktionen) hat für mich nichts mehr damit zu tun da bin ich voll bei dir @Retrofan, dieser Mode wird aber bestimmt auch seine Fans finden. Es hängt soviel davon ab was der Kasten nachher wirklich kosten wird und wieviele davon verkauft werden (und wann er denn erscheint).

    M. J. schrieb:

    Der C65 hingegen bekam nur eine 8 Bit-CPU mit 3,5 Mhz zugebilligt. Damit hätte man ein paar nette Standbilder hinbekommen, aber keine flüssige Spielgraphik, die die erweiterten Fähigkeiten ausnutzen kann. Hinzukommt noch der für höhere Auflösungen extrem knappe Speicher von 128 kb und das lästige Banking. Anders gesagt: Für die angestrebte graphische Auflösung war der Rechner viel zu unterdimensioniert.
    Genau deswegen hat der C64 mit 0,98 MHz ja auch nur Standbilder. Der 4510 Prozessor hat zusätzliche Befehle um das RAM ziemlich einfach zu adressieren, außerdem ist der DMAagic da, Standbilder rum schieben muss also nicht die CPU machen...

    Auszug aus dem Link oben

    1.2. System Overview
    CPU -- Commodore CSG4510 running at 1.02 or 3.5 Mhz
    New instructions, including Rockwell and GTE extensions
    Memory Mapper supporting up to 1 Megabyte address space (der C65 hatte einen Erweiterungsschacht ganz ähnlich wie der Amiga 500)
    ...

    DMA -- Custom DMAgic controller chip built-in
    Absolute address access to entire 8MB system map
    including I/O devices, both ROM & RAM expansion ports.
    List-based DMA structures can be chained together
    Copy (up,down,invert), Fill, Swap, Mix (boolean Minterms)
    Hold, Modulus (window), Interrupt, and Resume modes,
    Block operations from 1 byte to 64K bytes
    DRQ handshaking for I/O devices
    Built-in support for (optional) expansion RAM controller

    Damit sind nette Dinge denkbar ;)
    +60K Speichererweiterung für den C64, TapeDevil Toolcollection fürs TapeCart
    C64 [Assy 250466, 1541U2+, MixSiD, Keyman64, Overlay64, Reprom64, AC/64]; U64 [2xARMSID]
    A500+ [Rev 8A1, A1k-TK-SRAM-IDE], A600 [Rev 1.3, ACA620], A1200 [Rev. 2B, ACA1233n]
  • Markaine schrieb:

    Genau deswegen hat der C64 mit 0,98 MHz ja auch nur Standbilder.
    Sorry, das habe ich nicht verstanden. :nixwiss:

    Markaine schrieb:

    Der 4510 Prozessor hat zusätzliche Befehle um das RAM ziemlich einfach zu adressieren
    Nö. Der Original-Prozessor von Commodore ist ein 8 Bit-Prozessor mit 16 Bit (64 Kb)-Adreßraum. Alles, was darüber hinausgeht, muß durch Banking eingeblendet werden. "Einfache" Adressierung würde zumindest bedeuten, daß man eine Speicherzelle direkt ansprechen kann wie beim 65816. Das ist hier nicht der Fall.

    Markaine schrieb:

    außerdem ist der DMAagic da, Standbilder rum schieben muss also nicht die CPU machen...
    Rechnen wir das doch einfach mal durch:

    - Der 6502 beim C64 hat (grob gesagt) ca. 1.000.000 Taktzyklen pro Sekunde und damit folglich 1.000.000 / 50 = 20000 Taktzyklen pro Bildschirmaufbau. Der reine Kopiervorgang (ohne Prozessorbefehle) von 1000 Zeichen des Textbildschirms zum Scrollen der Anzeige benötigt hiervon 2000 Taktzyklen (1000 zum Laden, 1000 zum Speichern). Damit bleiben noch ausreichend Taktzyklen frei für die Programmlogik (und entsprechend weniger, wenn man auch das Farbram scrollen will).
    - Der C65 hat einen erhöhten Takt und kommt auf ca. 3.500.000 Taktzyklen pro Sekunde und damit auf 3.500.000 / 50 = 70000 Taktzyklen pro Bildschirmaufbau. Eine 320x200x4 Bitmap benötigt 32000 Bytes. Auch mit Blitter braucht man zum Kopieren mindestens 64000 Taktzyklen von 70000 zur Verfügung stehenden, hat aber immer noch kein einziges Shape gemalt oder irgendeine Programmlogik ausgeführt.

    - Der C64 braucht zum Scrollen des Zeichensatzes 1000 + 2048 Bytes für eine komplette Anzeige aufgrund des Zeichensatzmodus. Für das saubere Scrollen in alle Richtungen verwendet man gerne Double-Buffering, was dann weitere 1000 Bytes bedeutet. Damit bleibt bei 64 kb Speicher noch genügend Platz für Sprites, Landschaftsdaten, Programmcode usw.
    - Der C65 benötigt für eine 320x200x4 Bitmap 32000 Bytes. Für ein Doublebuffering 64000 Bytes, was bereits die Hälfte des 128 KB-Speichers bedeutet. Alle weiteren Graphikdaten (Shapes oder Tiles) müssen der Auflösung entsprechend als 16 Farben-Daten vorliegen, was wesentlich mehr Platz benötigt als die Spritedaten beim C64. Damit werden auch die anderen 64 Kb sehr schnell gefüllt.

    - Die Verwendung von Shapes anstelle von Sprites verlangt wie beim Amiga oder AtariST, daß man Algorithmen verwendet, die dafür sorgen, daß der Bildschirmhintergrund wiederhergestellt wird, z. B. indem die Hintergrundgraphik in einen Puffer kopiert wird. (Bei Double-Buffering verdoppelt sich der Bedarf.) Je nach dem, welche Methode man wählt, füllt sich der Speicher weiter...

    Nur mal so zum Vergleich: Man schaue sich an, wieviel Speicher Programme wie R-Type oder Katakis auf dem Amiga bzw. AtariST belegen. Dann stelle man sich vor, daß sie nur 128 Kb zur Verfügung hätten. Dann sage man ehrlich, ob man es für möglich hält, daß solche Spiele auf einem 128 Kb Computer mit 8 Bit CPU möglich sind. Sorry, aber da hilft dann auch kein Blitter mehr.
  • Neu

    Da ich mich technisch und insbesondere programmiertechnisch bei weitem nicht so gut auskenne wie M.J., frage ich mal vorsichtig nach:
    Ist es nicht ein wenig Äpfel mit Birnen vergleichen, wenn man das Zeichensatzscrolling vom C64 mit Bitmapscrolling auf dem C65 vergleicht? Ich meine: Wie viel CPU- Geschwindigkeit hätte man denn auf dem C64 übrig, wenn man in Spielen Bitmapscrolling verwenden würde?
  • Neu

    Also, C65 Bitmap Modus usw. sind "interessant", könnte man sagen.
    Am erstens haben wir genau wie mit dem C64, aber man kann auch 640x200 oder 640x400 dabei ershaffen. Hier kommt keine Überraschungen, aber auch nicht viele Vorteilen dabei. 320x200 mit 4 Farben aber wird für Spiele etwas hilfreich. Die Palete des C65 kann auch hier benutzt, dass man jeder 4 von die ganzen 4.096 Farben auswählen.

    Die Sprites sind genau wie mit der C64. Das Heißt, es gibt kein 640x200 oder 640x400 Sprite Modus. Das ist etwas von einer Mist, weil 320x200 4 Farbige Sprites wäre auch nützlich gewesen.

    Dann kommt die Bitplanes. Hier gibt es einige eher größe Nervigkeiten, so finde ich. Die größte Dummheit ist einfach, dass man die Anfangsadressen der Bitplanes nicht richtig ändern. Auch kann man nicht die Logikalische Große der Bitplanes ändern. Deshalb muss man alle 8KB (oder 16KB bei 640x200, usw...) in Bewegung stellen, das Bild zu scrollen. Auch muss man mehr Puffern haben, was ganz unhilfreich bei eimen Rechner mit nur 128KB Speicher sei.

    Ich verstehe, dass diese unbenötigten Begrenzungen war teilweise weil die Marketingtypen wollten nicht, dass der C65 einen Konkurenz des Amigas sein könnte. Es ist die gleiche Geschichte wie mit dem C128, wo die Marketingtypen wollte nicht, dass das C128 weder mehr als 128KB Speichere haben könnte noch der Erhöherte Speichergröße des C128s in C64 Modus benutzt sein könnte (obwohl auf anderer Gründe).

    Dann füge hinzu die schneckenartige DOS Routinen (wie man könnte vergeben werden, wenn er denkt es war ein Art Tradition des Commodores die Laufwerken so langsam wie möglich zu machen) und der Erfolg war wahnsinnige langsam laden des Graphics und kaum Vorteile des Machines im vergleich mit dem C64 und das Ding war abgelehnt und ging nicht weiter. Dabei ist die Maschine ausgestorben bevor sie das Tageslicht sah, genau wie das Einhorn wegen es konnte nur Regenbogen pupsen und deshalb war der Wirtschaft fast nutzlos (aber wenn die "Big Pharma" noch ein Einhorn kriegen könnte, dann könnte die Einhorne noch am leben sein, aber ganz sicher unter eine Bergkette Patente zerquetscht geworden).

    Allerdings, wie wir alle schon wissen, der ursprüngliche C65 war nicht besonders Praktisch als neuer Computer. Aber machte immer noch Spaß zu benutzen :)

    Paul.
  • Neu

    enthusi schrieb:

    Niemand (+/- 3) wird dafuer programmieren.
    Das ist jetzt aber schon ein wenig pessimistisch, meinst nicht?

    WalkThatWay schrieb:

    @M. J. ich hatte @mega65 so verstanden, das im C65 Modus die komplette Palette der Möglichkeiten des C64 genutzt werden kann. Ich bin also nicht auf den Bitmapmodus festgenagelt.
    Das vielleicht nicht, aber die letzten fachlichen Beiträge zum Thema C65 klingen für mich wie ein überhasteter Schnellschuß, ohne die einzelnen Möglichkeiten zu Ende gedacht zu haben. Toll, dass es mehr Farben gibt, aber wenn ich sie nicht nutzen kann, mangels Performance - was nutzen sie mir dann? Toll, dass es neue Grafikmodi gibt, aber wenn der Speicher und der Systemtakt nicht ausreichen - was soll ich damit anfangen? WOLLTE man nichts davon verkaufen, als man anfing zu entwickeln, oder hatte man nur keinen fähigen Entwickler (mehr), der in der Lage war, ein neues System zu entwerfen?!?!? ;(
    VIC20 / C64 / C128 / C16 / C+4 / Amiga 500 / Amiga 2000 / Amiga 1200 / Amiga 4000 / Amiga 4000 PPC / CD32 / PlayStation / PS2 / PS3 / PS4 / N64 / Wii / WiiU / Switch - hab ich! :D
  • Neu

    Boulderdash64 schrieb:

    ... die letzten fachlichen Beiträge zum Thema C65 klingen für mich wie ein überhasteter Schnellschuß ... WOLLTE man nichts davon verkaufen, als man anfing zu entwickeln, oder hatte man nur keinen fähigen Entwickler (mehr), der in der Lage war, ein neues System zu entwerfen?!?!? ;(

    Ich glaube auch, dass zu viele Nichttechnikrer bei den Specs mitbestimmt haben. Ja nicht den Amigas zu nahe kommen, aber die noch verbliebenen, umsteigeunwilligen C 64 Fans mit bunten Standbildern locken.
  • Neu

    WalkThatWay schrieb:

    ich hatte @mega65 so verstanden, das im C65 Modus die komplette Palette der Möglichkeiten des C64 genutzt werden kann. Ich bin also nicht auf den Bitmapmodus festgenagelt.
    Als Programmierer hast Du selbstverständlich die freie Wahl, welche Darstellungsmodi Du verwenden möchtest. Allerdings... Wenn man nur die alten Modi des C64 verwendet, hat man halt auch nur einen C64 mit 3,5 Mhz. Mehr nicht. Da kann man schon die Frage stellen: Was soll das...? Zum Vergleich noch einmal der Apple//gs: Man stelle sich vor, Programmierer hätten gesagt "Oh, wir haben jetzt einen schnelleren Apple// mit 16 Bit-Prozessor. Super. Jetzt programmieren wir Spiele für den Apple//, aber verwenden dabei nur die alten Graphikmöglichkeiten und lassen alles Neue links liegen." Welchen Anklang hätte das gefunden? Wieviele Spiele wurden auf diese Weise programmiert? (Antworten: Null und null.)

    fenris64 schrieb:

    Da ich mich technisch und insbesondere programmiertechnisch bei weitem nicht so gut auskenne wie M.J., frage ich mal vorsichtig nach:
    Ist es nicht ein wenig Äpfel mit Birnen vergleichen, wenn man das Zeichensatzscrolling vom C64 mit Bitmapscrolling auf dem C65 vergleicht? Ich meine: Wie viel CPU- Geschwindigkeit hätte man denn auf dem C64 übrig, wenn man in Spielen Bitmapscrolling verwenden würde?
    (Du kannst auch gerne unvorsichtig fragen. ^^ )
    Natürlich ist es auf den ersten Blick ein schräger Vergleich zwischen Zeichensatzgraphik und Bitmapgraphik, aber so sind diese Rechner nun einmal konzipiert. Die wirklich neuen Modi des C65 sind Bitmapmodi. Sofern die Informationen auf c64-wiki korrekt sind, hat man, was den Zeichensatz anbelangt, die Textdarstellung lediglich erweitert um die überflüssigen Attribute "blinken", "fett" und "unterstrichen". Schon 1990 war klar zu erkennen, daß die Textausgabe über einen Textmodus nicht mehr zeitgemäß war. Man schaue sich nur mal die Text-Software auf dem AtariST an. Selbst der CPC kannte keine reine Textdarstellung, sondern nur noch Bitmap. Längst sprossen überall auf den Rechnern fensterbasierte GUIs, aber der C65 sollte als Basisdarstellung immer noch über eine reine Textausgabe verfügen wie vor zehn Jahren: keine mehrfachen Zeichensätze, keine Proportionalschrift, nicht einmal Kursiv. Von daher sind die neuen Bitmapdarstellungen das Einzige, was den C65 interessant machen könnte, nur leider scheitert der praktische Einsatz - wie beschrieben - an mangelnder Rechenleistung.

    Um die Frage aber nun konkret zu beantworten: Auf dem C64 ist ein Scrollen der Bitmap durchaus möglich (s. zum Beispiel die Adventures von Magnetic Scrolls). Läßt man die Graphik langsam scrollen um ein Pixel pro Bildschirmaufbau, so hat man für das komplette Umkopieren bzw. Neuzeichnen der Graphik 8 Frames Zeit. Das ist tatsächlich ausreichend, um einfache Spiele zu gestalten. Daß dies in der Praxis kaum gemacht wird, liegt an einigen Gründen:
    - Mit Bitmapgraphik ist kein (Pseudo)Parallax-Scrolling möglich mittels Rotieren von einigen Zeichen im Zeichensatz (z. B. bei R-Type). Auch stillstehende Sterne (wie bei Uridium) lassen sich nur aufwendig realisieren.
    - Mit Bitmapgraphik kann man keine zusätzlichen Schüsse durch Zeichen darstellen. Spiele wie Katakis, Uridium oder Delta benutzen für die Darstellung ihrer zahlreichen Schüssen Zeichen und nicht Sprites. Für eine größere Anzahl von frei bewegbaren Figuren auf dem Bildschirm wäre ein Spritemultiplexer wohl Pflicht, jedoch bleibt es auch bei diesem bei der Einschränkung von 8 Sprites pro Rasterzeile.
    - Ähnlich wie beim Parallax-Scrolling läßt sich der Hintergrund nicht so einfach animieren, sei es durch Abändern der Zeichen im Zeichensatz oder durch Austauschen von Zeichen in den Landschaftsdaten.
    - Beim Zeichensatzscrolling liegt oftmals die zu scrollende Landschaft komplett im Speicher vor und wird aus diesem Puffer direkt in den Bildschirmspeicher kopiert. (Uridium z. B. entpackt vor jedem Level die Leveldaten in einen solchen Puffer.) Bei Bitmapgraphik liegen die Daten wahrscheinlich auch als Kacheln vor, doch entsprechen diese Kacheln eben keinen zu kopierenden Zeichenbytes, sondern müssen vom Programm Stück für Stück als Shape in die Bitmap kopiert werden. Dieser Aufwand ist auch mit Blitter ziemlich groß.

    Bei einem Spiel, das ohne Sprites auskommen muß (der C65 hat keine eigenen Sprites), geht man gewöhnlich so vor:
    1.) Malen des Hintergrunds in Bitmap 1
    2.) Malen der Figurenshapes in Bitmap 1
    3.) Umschalten der Anzeige auf Bitmap 1
    4.) Malen des Hintergrunds in Bitmap 2
    5.) Malen der Figurenshapes in Bitmap 2
    6.) Umschalten der Anzeige auf Bitmap 2
    Hierbei spart man sich bei schnelleren Prozessoren das (sehr) aufwendige Löschen der Figuren vom Schirm und Restaurieren des Hintergrunds, indem radikal (brute force) der Hintergrund komplett neu gezeichnet wird. Ein richtiges Scrollen des Hintergrunds, d. h. ein Umkopieren der Bitmap, findet gar nicht mehr statt. Schnelle Prozessoren simulieren sozusagen ihren eigenen Zeichensatz-Modus. Der Prozessor im C65 ist dafür aber nicht geeignet. Angenommen, man wollte stattdessen ein echtes Scrollen haben durch Umkopieren, so müßte man entweder den Hintergrund hinter den Figuren (wie bereits erwähnt) puffern oder ihn aufwendig restaurieren (teilweises Kachelneuzeichnen) oder Triple-Buffering verwenden:
    1.) Kopieren der Hintergrunddaten von Bitmap 1 auf Bitmap 2
    2.) Malen der FIguren in Bitmap 1
    3.) Umschalten der Anzeige auf Bitmap 1
    4.) Kopieren der Hintergrunddaten von Bitmap 2 auf Bitmap 3
    5.) Malen der Figuren in Bitmap 2
    6.) Umschalten der Anzeige auf Bitmap 2
    7.) Kopieren der Hintergrunddaten von Bitmap 3 auf Bitmap 1
    8.) Malen der Figuren in Bitmap 3
    9.) Umschalten der Anzeige auf Bitmap 3
    Dieses Verfahren schluckt viel Speicher für die zusätzliche Bitmap und wäre z. B. auf einem Amiga500 oder AtariST eine Alternative. Auf dem C65 mit seinen 128 kb hingegen schluckt dieses Verfahren sehr, sehr viel kostbaren Speicherplatz.

    Natürlich lassen sich Spiele schreiben, die a) einen neuen Bitmap-Modus des C65 verwenden, b) Figuren dann über C64-Sprites darstellen. Dann hätte man vielleicht eine besser aussehende Hintergrundgraphik, aber darauf die eher unpassenden klobigen Sprites des C64 und dazu noch alle oben genannten Einschränkungen be der Verwendung von Bitmapgraphik. Schwierig bleibt aber weiterhin das Timingproblem, denn es muß ja im Vergleich zur Bitmap des C64 die vierfache Menge an Bildschirmdaten umkopiert werden.
  • Neu

    M. J. schrieb:

    Die Verwendung von Shapes anstelle von Sprites verlangt wie beim Amiga oder AtariST, daß man Algorithmen verwendet, die dafür sorgen, daß der Bildschirmhintergrund wiederhergestellt wird, z. B. indem die Hintergrundgraphik in einen Puffer kopiert wird.

    In den C 65 Specs ist ja auf Seite 106 auch von "Multiple (2-8) playfields" die Rede. Falls damit 'double playfields' wie beim Amiga gemeint sind, also zwei oder noch mehr unabhängige Malebenen, könnte das Retten und Wiederstellen des Hintergrunds entfallen, bei entsprechend geringer Farbtiefe pro Ebene natürlich.
  • Neu

    ogd schrieb:

    In den C 65 Specs ist ja auf Seite 106 auch von "Multiple (2-8) playfields" die Rede. Falls damit 'double playfields' wie beim Amiga gemeint sind, also zwei oder noch mehr unabhängige Malebenen, könnte das Retten und Wiederstellen des Hintergrunds entfallen, bei entsprechend geringer Farbtiefe pro Ebene natürlich.
    Ich befürchte, daß selbst unabhängige Playfields (wie z. B. beim Amiga) nicht viel weiterhelfen. Um sie zu verwenden, bräuchte jedes Playfield ausreichend Puffer für ein Doublebuffering, damit das Umkopieren des Hintergrunds und das Löschen und Malen der Shapes unsichtbar vonstatten gehen kann. Dieser Speicheraufwand dürfte sich aber wieder beißen mit den 128 kb des Original C65.
  • Benutzer online 2

    2 Besucher