Ich kann regelrecht spüren, dass im CPC noch unentdeckte Tricks stecken.
Wäre ich schizophren, könnte ich es nicht nur spüren, ich könnte es auch hören, gar auch sehen!

Schade, dass die posthume CPC-Szene längst nicht so groß ist wie die 64er-Gemeinde, die mit vereinten Kräften wie im Wahn alles aus der Kiste herausholt.

Nun, einfach mal abwarten, vielleicht tut sich noch was auf.

Ich bin ja mal gespannt, was der CPC noch so alles in der Hose hat. Bin mir recht sicher, dass da noch der ein oder andere Trick in die Tiefen des Rechners lauert.

Gab ja ne Menge erstaunlicher Games die letzten 10 Jahre.

"Combat" ?

Das! war dann wohl auch das, was ich als Bub in den 80ern, so eine Zwei-Spielekonsole per Kabel an die Röhre klemmte.

Da brachen mit der Zeit die Steuerhebel an der Station ab, und den Panzer danach mit Streichholz gesteuert, Mensch war das damals ein Spaß gewesen

es ist auf *jeden fall* von vorteil, kleineren bildschirmausschnitt zu haben zwecks performance.

es ist auf *jeden fall* schwieriger, dinge auf dem cpc so flüssig (weil *immer noch* aufwändigerere grafik, auch bei reduzierterem bildschirmausschnitt) wie auf dem spectrum hinzukriegen, v.a. wenn dieser bereits exzellent ausgereizt wird.

was aber natürlich nicht heißt dass es trotzdem 'nen haufen schlampiger ports gibt, die man auf dem cpc besser hätte machen können, kann aber als software-entwickler (in anderen bereichen) auch verstehen, dass man da oft nicht die zeit/ressourcen dafür hatte.

double-buffering-technik ermöglicht komplexere games, ermöglicht flackerfreiheit, aber benötigt mehr speicher (man schreibt updates in den zweiten framebuffer, während der erste gemalt wird, und tauscht diese buffers dann immer blitzschnell aus).

beispiel wäre wohl sowas wie renegade oder gryzor.

ein spiel das wohl ohne so framebuffer-techniken und eher bereits mit so demo-techniken, die ich beschrieben habe, funktioniert, ist wahrscheinlich dieser sensible-soccer-clone von neulich. ist sehr performant, aber ja auch ein wenig flackernd, wohl weil man manche dinge schwer unter kontrolle kriegen kann.

Hey, cool, Grumbler. Sehr netter Beitrag.
Vielleicht liegen ja noch Möglichkeiten brach, die dem CPC nochmal nen Schub geben könnten.

Doch liegt der recht oft zu sehende kleine Bildschirmausschnitt nicht auch am "Double Buffering"? Wobei ich ehrlich gesagt gar nicht so genau weiß, was das ist, bzw. wie das geht. Was ich weiß, ist, dass mit dieser Technik versucht wird, flüssiger zu sein.

Und warum gibt es Games, die vielleicht 1/3 des Bildschirms nutzen, und trotzdem ihre 6-8fps abfeuern? Gerade bei älteren Sachen. Alles falsch gemacht im Code?

Wenn ein Game auf dem Spectrum flüssig läuft, auf dem CPC jedoch nicht, müsste es mit reduziertem Spielfeld auf dem CPC doch auch flüssig laufen. Doch liegt es nur am Videoram? Oder spielen weitere Faktoren mit rein? Nicht wenige Games laufen auf dem Spectrum flüssiger. Oder liegt das an den wenigen Farben?

Fragen über Fragen.

das mit dem weniger video ram hat man ja oft genug gemacht, immer wenn der bildschirmausschnitt kleiner war, lag nich nur an dem lazy speccy porting alleine.

denk mir aber letztens auch dinge in der richtung.

was man machen kann ist den grafikcontroller direkt ansprechen und quasi den bildschirmspeicher umgehen.

das wären dann techniken, die ähnlich wie bei demos funktionieren.

es heißt aber immer, dass wär dann zu schwierig mit timing etc, gute spiele zu schreiben mit solchen techniken.

*aber*, so hat man auf dem atari 2600 ja auch programmiert, "racing the beam", man machte alles während der elektronenstrahl über den bildschirm sauste. der atari 2600 hatte ja fast kein ram und wurd *nur* dazu gebaut, um varianten von pong und combat (das mit den zwei panzern) zu bauen. quasi alles was darüber hinausgeht, die gesamte software-bibliothek, sind "demo"-techniken. fast alle atari 2600-spiele bestehen aus dem vorgänger der copper-/raster-balken, von sprite-multiplexing, und weiteren tricks.

würd vielleicht fürn anfang mal gern ein paar ports von atari 2600 spielen sehen, die vielleicht primitiv sind, aber am amstrad dann auch flüssig mit 50 hz laufen.

und *dann* mal schaun, was noch möglich wär, wenn man schon mehr speicher hat.

fast alle späteren 8bit- und 16bit-konsolen hatten auch nicht viel ram und benutzen ja auch keinen vollen bitmap-framebuffer, sondern tiles und sprites. die waren fest verdrahtete baukästen, wo man nur angeben konnte, während der elektronenstrahl über den bildschirm sauste, tu mal hier ein sprite malen, oder den hintergrund von der tilemap. vielleicht kann man in der richtung aufm amstrad auch was machen, wenn man den grafikcontroller direkter anspricht.
Kommentar wurde am 30.05.2021, 21:23 von Grumbler editiert.

Wenn ich das richtig verstanden habe, bremst die Größe des Video-Rams beim CPC den Z80 aus, weil zu viele Taktzyklen beim Füllen des Speichers gebraucht werden.

Doch ist das große Video-Ram auch für etwas gut?

Und könnte man nicht mit einem "Software-Trick" dem Rechner vorgaukeln, das Video-Ram sei nur halb so groß? Um dadurch Rechenzeit zu gewinnen?

Ui, am selben Tag wie Herbi & Herbie (Herbi Grönemeyer wird heute 65; Herbie Hancock 81).

Bin ja mal gespannt, ob das mutmaßlich sensationelle Autorennen der Batman-Gruppe mal irgendwann doch noch erscheinen wird.

Nach dem vollmundigen Trailer hörte man nie wieder was davon.

Ich aktiviere bzw. deaktiviere immer die Cartridge-Option bei WinApe; je nachdem, ob ich Disketten oder Module nutze. Gedächtnisprotokoll, muß nicht stimmen.

Weiß jemand, wie ich eine Cartridge aus dem CPC-Emulator WinApe V.20B2 werfe? Ich habe aus der akuellen DEV mal Alcon2020 versucht und nun kann ich die Cartridge nicht mehr entnehmen und der Emulator startet nur noch mit diesem Game!

ich bin eben nun mal kein Schwein sein in dieser Welt