Ja, ich hab die neueste Firmware drauf. Danke für das C64-Maustest-Tool.
Denn ich habe nur Lords of Doom, EOB und Geos zum testen. Geos hab ich nur V1.2 (da hab ich keine Umstellung für die Maus gefunden. Bei EOB müsste ja gleich im Menü der Mauszeiger kommen, oder?

Was muss ich in der ini für die C64Maus einstellen?

Ok, die A500Mini-Joypads und der The64Stick sind nicht so gut, aber in den letzten Firmware-Updates hatte etwas von besserer Unterstützung der Speedlinks CPs gestanden, daher hab ich gehofft.

Meine Thrustmaster-Funk-Mäuse gehen auch noch nicht.

Aber trotzdem bin ich zufrieden, das ich jetzt keine Kugelmaus mehr brauche.

Also ehrlich, wieso willst du solche Gurken am echten C64 per mouSTer nutzen? Teste mal eine vernünftige PC USB HID Maus.

Für den vollen C1351 Support empfehle ich die letzte Beta Firmware (auf "Assets" klicken). Die läuft damit super am C64, sogar mit 3-Button Support und Mausrad Unterstützung. Eye of the Beholder geht bestens damit, mouSTer in Port 2. Die Mausfunktion kann man auch wunderbar mit dem Joyride Tool austesten.
LINK

Kleiner Tipp: Auf dem USB Stick im mouster Ordner die "MOUSTER.INI" öffnen und ganz oben nachschauen, ob überhaupt die aktuellste Firmeware und ini. draufgeflasht wurde. Das korrekte hochladen vom USB Stick auf den Adapter erkennt man an dem 1-2 sekündigen sehr schnellen blinken.
Kommentar wurde am 03.03.2023, 20:08 von Retro-Nerd editiert.

AAARGH! Ich bekomme mit meinem USB-Adapter mouSTer keinen C1351 Support hin. Ich hab die neueste Firmware und in der ini nicht auf Auto, sondern Mouse gestellt und dazu bei den Mouseeinstellungen=c1351 gewählt. Dann eob gestartet und nix. Maus geht nicht. Komischerweise reagiert auch nicht die F1-Taste bei EOB, wo man die Maus auswählt.

Am Amiga geht die A500-Mini-Maus super, aber die Speedlink CPs nicht! Shit! Sega Mega Drive USB und Xbox360-Controller geht, Der The64-CP und A500-MiniJoypad nicht.

Die Speedlink Competitions Anniversary wären mir neben der A500MiniTankmaus am wichtigsten gewesen.
Kommentar wurde am 03.03.2023, 19:05 von Commodus editiert.

Beim NES müsste man vermutlich die einzelnen Mapper durchgehen. Das NES ist in seiner Basis-Ausstattung bei Scrolling wohl recht eingeschränkt.



Ist beim Atari Lynx ähnlich
Kommentar wurde am 26.02.2023, 20:58 von v3to editiert.

Auch ziemlich trivial und löst das "Byte-Parität"-Problem beim Ansatz mit Bildaufbau-Startadresse setzen, wenn man (stattdessen? zusätzlich?) das Offset zum Rendern der Tilemap setzen kann.



Ich glaube bereits etwa das NES hatte das Konzept einer gesamten (oder großen) Tilemap (die direkt vom ROM ausgelesen wird auf auf den Bildschirm projiziert wird?), so dass man nicht mehr (oder selten) umkopieren musste.



1 Byte = Wert von 0-255.
2, 4 oder 16 Farben ungleich 256.

Es werden also in einem Byte im Bildschirmspeicher mehrere Pixel zusammengefasst.

> Das Neo-Geo etwa macht dann offiziell keinen Unterschied mehr zwischen Tiles und Sprites.

Die Pointe hab ich hier quasi vergessen zu erwähnen. Der Amstrad CPC hat quasi Hardware-Scrolling, aber das Neo-Geo eigentlich nicht. (Ich glaube, es unterstützt zwar einen statischen Bitmap-Hintergrund, aber den kann man wohl nicht scrollen. Es wird alles mit Sprites gemacht.)
Kommentar wurde am 26.02.2023, 20:31 von Grumbler editiert.

Da! Captain Future in Dual SID!

LINK

Die Byte was?

Und was haben die mit den Farben zu tun?

Das ist typisch 8 Bit der 80er. Egal ob Homecomputer oder Spielekonsole. Die Hintergrundgrafik besteht aus Zeichensatz und nicht aus Bitmapgrafik, weil man so nicht so viel umkopieren muss.

Beim Amiga lässt sich eine Parallax-Ebene auch aus gemultiplexten Sprites bilden. Das wurde zb bei Turrican in Shmup-Abschnitten oder Apydia gemacht. Das ist eine Möglichkeit, um für die Vordergrundgrafik Farbeinschränkungen des Dual-Playfield-Modus zu umgehen.

Beim C64 ist der Begriff Hardware-Scrolling in Bezug auf die Scroll-Register des VIC durchaus geläufig. Wobei das vermutlich auch eine Definitionsfrage ist, da das für sich genommen keine Scroll-Routine setzt und alle 8 Pixel der Bildschirminhalt umkopiert werden muss.
Kommentar wurde am 13.02.2023, 17:57 von v3to editiert.

wie schon mal beschrieben ist "Hardware-Scrolling" eh sowas wie ein Mythos. Es ist eher eine Eigenschaft oder Funktion, die sich aus anderen Eigenschaften der Grafikhardware fast automatisch ergibt.

Im Gegensatz zu dedizierter Sprites-Funktionalität, die tatsächlich relativ aufwändig mit genau dafür entworfenen Schaltkreisen implementiert wird, benötigt man für "Hardware-Scrolling" eigentlich lediglich eine Möglichkeit, die Anfangsadresse für den Bildaufbau zu setzen. Das ist relativ trivial. Fast alle Maschinen der 80er können das. (Nur der Speccy nicht.)

Der CPC z.B. hat ja bekanntlich durchaus diese Funktion, "nur" gibt's da noch das Problem, dass die Byte-Parität mit der Anzahl der Farben (egal welcher Modus) nicht übereinstimmt, drum kann man nicht 1-Pixel-weise scrollen. Außerdem bringt Hardware-Scrolling nicht viel in Bezug auf Entlastung des Hauptprozessors, wenn man keine Sprites hat.

Ein Modus/Funktion für Hintergrund-Tiles/Characters wie beim C64 oder Konsolen hätte dem Abhilfe geschaffen, und wenn er noch Sprites gehabt hätte, dann hätt sich das "richtige Hardware-Scrolling" ebenso ergeben, und der Amstrad wär 'ne richtige 80er-Spielhöllenmaschine geworden.

Mit dieser Sichtweise wird vielleicht auch intuitiv klarer, dass auf dem C64 die Tricks, die v3to beschreibt, nötig waren, um die Illusion eines "Parallax"-"Hardware-Scrolling" hinzukriegen.

Beim Amiga geht ergibt sich das "Hardware"-Parallax-Scrolling (vermute ich) vor allem durch die Bitplanes-Funktion. Modernere (16-Bit) Konsolen haben dann bereits so viel Power, dass sie so viele Sprites darstellen können, dass man diese auch als weitere Hintergrundebenen zusammenklatschen und verwenden kann, die sich dann anders bewegen als der eigentliche Hintergrund. Das Neo-Geo etwa macht dann offiziell keinen Unterschied mehr zwischen Tiles und Sprites.

Anderes Beispiel: der Atari 2600. Eigentlich ist das Ding nicht bekannt für "Hardware-Scrolling". Aber schau dir mal Jungle Hunt an. Butterweich alles. Und parallax! Bei der Kiste muss man halt eh alles mit der CPU machen, "live" den Bildaufbau Rasterzeile für Rasterzeile (und teilweise auch innerhalb der Zeile) manipulieren, Techniken also, mit denen man später dann Demos machte ("Mit Demo-Methoden kann man keine Spiele machen!" Von wegen. Das war damals Standard.) Ich glaub solche "einfachen", aber sauber scrollenden Games wären auch auf dem CPC möglich, aber niemand möchte mehr solche einfachen Games, und deshalb macht sich niemand die Mühe.
Kommentar wurde am 13.02.2023, 17:24 von Grumbler editiert.

Also gibt es den Hardware-Scroll nur einmal, gell?

An sich kann man Parallax-Scrolling auf dem C64 auf drei Varianten beschränken - jedenfalls, wenn man mal Sprites beiseite lässt:

- Pattern-Animationen. Das sind meist Kacheln von idr 2x2 Zeichen (also 16x16 Pixel)... z.B. bei X-Out oder Katakis
- Horizontale Splits, die in unterschiedlichem Tempo scrollen... das ist so wie in Moon Patrol oder Silkworm
- Kombination von Durchwechseln von 4 Zeichensätzen und Umkopieren der Hintergrundebene alle 4 Pixel... das wurde zb bei Hawkeye, Rubicon gemacht

Die Pattern-Methode funktioniert an sich in alle Richtungen und es gibt manchmal auch Varianten, wo das Muster auch noch animiert wird oder vertikale Splits simuliert werden.
Die anderen beiden Varianten funktionieren an sich nur bei horizontalem Scrolling und dazu ist die Hawkeye-Methode auch ein Ressourcenfresser.

Es ist auch möglich, die drei Ansätze zu kombinieren, wie z.B. im ersten Shmup-Level von Turrican 2.

Das dürfte aber bei allen 8bit CPUs so sein. Wurde erst leicht mit 16bit.

Danke! Also gar nicht so einfach, Griff in die Trickkiste nötig.