c64 Sprites...

c64 Sprites... (18 Beiträge, 896 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Bin wieder mal auf dem Nostalgietrip - und scheiter gerade:

Laut Handbuch, Frisch nach dem Einschalten:
Sprite-Daten: Auf PEEK(2040)*64
VIC auf 53248
Sprite 0 X-position: VIC+0
Sprite 0 Y-position: VIC+1
...
Sprite enable: VIC+21

Mein Ablauf ist wie folgt:

10 SP=46
20 POKE 2040,SP
30 SP=SP*64
50 POKE 53248+21,1
60 POKE 53248,100
70 POKE 53249,100

run

Wenn ich nachher

poke SP,0
poke SP,100

durchführe, sehe ich die Änderungen am Sprite.

Wenn ich die Zeile 10 aber ersetze - zB durch

10 SP=64

funktioniert es nicht mehr.... Scheinbar klappt es bei allen SP>= 64 nicht.
Ein POKE SP, ... bewirkt nichts... Obwohl ich mich im unbenutzten Basic-Ram bewege...
PEEKs zeigen auch, dass die POKES funktioniert haben.

Laut Dokus werden aber alle 8 Bits in 2040 verwendet - was mache ich falsch?

Komisch, dass die PEEKs zeigen dass das funktioniert, aber der Bereich ist doch eher "riskant" weil sehr niedrig im BASIC-RAM ... Das könnte evtl. auch temporär überschrieben werden wenn du etwas tippst (ohne Zeilennummer).

Warum nimmst du nicht z.B.

SPR11 02C0-02FE 704 Sprite #11 Data Area.

was stimmt mit meinem Netzzugang nicht? | wikileaks.geizhals.org

"Wenn Behörden solche Trojaner in Auftrag geben und sie benutzen, handelt es sich um eine neue Form der Staatskriminalität" (Heribert Prantl, sueddeutsche.de)

aber der Bereich ist doch eher "riskant" weil sehr niedrig im BASIC-RAM ...

Soweit ich mich erinnere, wächst der Basic-Code von unten nach oben - und Variablen von oben nach unten. Das bedeutet IMHO, dass ein niedriger Bereich eher nicht überschrieben werden sollte, solange ich keine neuen Zeilen einfüge.

Der Witz in dem Beispiel ist ja, dass ich gar keine Sprites definiere/poke, sondern das Sprite nur die zufälligen Daten an dem Ort anzeigen lasse. Mir geht es also noch nicht darum, die Sprites zu erzeugen, sondern sie nur zum Anzeigen zu verwenden. Wenn der VIC funktioniert, wie ich es mir denke, müsste das angezeigte Sprite nach Pokereien einfach anders aussehen... Und genauso, wenn die Daten zufällig verändert werden.

Warum ich das so möchte:
Ich schreibe gerade mit cc65 - gemischt C und Assembler.
Die Idee war nun, dass ich ein eigenes Segment definiere (Segmente sind bei CC65 einfach Bereiche für den Linker, die er unterschiedlich behandelt) - mit align=64.
Dort kommen die Sprite-Daten hin - mit
SPRITE1: .BYTE 0,255,...

Durch das Linken wird das Ding Bestandteil des Programms - ausgerichtet an eine durch 64 teilbare Adresse. Ich bräuchte sie daher nicht umverschieben, sondern könnte direkt die durch 64 geteilte Adresse in die nach 2040 schreiben.

Dieses Segment hatte ich als letztes in meinem Programm.

Einen Workaround habe ich inzwischen eh gefunden - ich lasse dieses Segment nun an eine frühere Stelle in das Programm linken. Meine Sprite-Daten starten dann ab $940, also 2368. Bis zum Wert 63 passt ja alles, was man nach 2040 schreibt. Das höchste Sprite ist bei diesem Ansatz also bei Position 4032. Ich kann also 27 Sprites so bequem definieren...

Unklar bleibt mir trotzdem, warum der VIC scheinbar nur 6bits für die Daten des Sprites verwendet. Ausprobiert habe ich alles am VICE-Emulator - und der ist ja schon seeehr perfekt.

Könnte ein simpler VIC Adress-Überlauf sein.
AFAIK kann der VIC II maximal 16384 Bytes auf einmal adressieren. Wenn du die Erste Seite im Speicher per VIC ansprichst, kannst Du also Adressen 0-16383 für Sprites nutzen. Willst Du Sprites im Bereich 32768-49151 nutzen, mußt du den Bereich auch für den Bildschirmspeicher des VIC nutzen.

Allerdings bin ich nicht ganz so fit beim C64, kann also nicht für die Infos garantieren. Mein Spezialgebiet ist der ZX Spectrum.

Könnte ein simpler VIC Adress-Überlauf sein.

Ja, es riecht voll danach.

AFAIK kann der VIC II maximal 16384 Bytes auf einmal adressieren.

Das glaube ich auch. Der Witz ist nun, dass Du als Adresse für die Sprites ein Byte hast... Dessen Inhalt wird mit 64 multipliziert, dort liegen deine Sprite-Daten.
256*64=16384 - das würde sich mit deiner These decken.

Stattdessen sieht es für mich so aus, als ob der VIC nur 4K an Spritedaten erreichen kann - von 0*64 bis 63*64. Und das kommt mir doch wenigst vor ....

Stattdessen sieht es für mich so aus, als ob der VIC nur 4K an Spritedaten
erreichen kann - von 0*64 bis 63*64. Und das kommt mir doch wenigst vor ....

diese alten 8-Bit Computer und deren noch ältere Zusatzchips konnten es eben nicht besser, trotzdem ist es doch verwunderlich, was damit bereits möglich war.

Ist schon weit mehr als 20 Jahre her, aber meiner Erinnerung nach sind für den C=64

eben nur diese 16384 Bytes für den Spritepointer zugänglich.

Mehr als 8 Sprites gleichzeigt ist nur über Assembler und Raster-Interruptprogrammiertricks möglich. Damals waren die ganzen Cracker- und Demogroups eigentlich nur an dieser Sache interessiert, diese Tricks vor den anderen zu "erfinden" und nebenbei das ein oder andere Game im Nachspann des Intros anzuhängen

Alles stimmt. Aber auch das Gegenteil.

Ja aber mein Problem ist ja, dass ich eben keine 16384 Bytes für Sprites zur Verfügung habe, sondern nur 64*64=4096...

Das mit den nur 8 Sprites gleichzeitig ist mir eh klar...
Ich will aber mehrere Sprites hinterlegen für verschiedene Bilder desselben Sprites, also für die Sprite-Animation.

Raster brauche ich noch nicht

.

Mir schwebt vor, den Kleinen (er ist 8) für Programmieren zu begeistern.
Wir haben uns als Ziel gesetzt, ein von uns gerne gespieltes Spiel nachzubauen: http://en.wikipedia.org/wiki/Sky_Diver
http://www.youtube.com/watch?v=CNjahwYZCZA

Wir brauchen also Sprites für
- 2 Flugzeuge
- 2 Springer
- 2 Plattformen
- Windfahne

Wenn wir in Phase 1 nicht mehrere Sprites übereinanderlegen um mehr Farben trotz HiRes zu haben - kommen wir schön aus

Wenn wir mehr Sprites brauchen, ist das Spiel für Raster auch dankbar.
Es gibt 3 vertikal schön abgegrenzte Bereiche:
Flugzeuge, Springer und Plattform - und in jedem Bereich genau 2 Objekte. Man kann also 4 Sprites pro Objekt verwenden

.

Sorry, das war oT...

Aber zurück:
Wie geschrieben, einen Workaround für das Problem habe ich bereits. Ich verstehe nur nicht, wieso das Problem auftritt. Alle möglichen Dokus verweisen, dass 16kb für Sprites nutzbar sind - und nicht nur die 4kb, die ich schaffe...

vielleicht überschreitest den Speicherbereich, auf den der VIC zugreifen kann.
Also die ersten paar Sprites werden noch im ersten Speicherbereich liegen, die anderen dann im zweiten ( die nächsten 16 kB), und der VIC kann nur entweder 1. oder 2. lesen.

Ich bin immer in den untersten 16K geblieben...

Habe aber soeben die Lösung gefunden:
https://sh.scs-trc.net/vic/vic_article_2.htm#2.4.2.

Da gibts
- 2.4.1 MEMORY MAP AS SEEN BY THE 6510
- 2.4.2 MEMORY MAP AS SEEN BY THE VIC

Und genau hier war mein Fehler:
Der VIC sieht in jeder der 4 16KB-Bänke immer ab Position $1000 (also genau, wenn ich 64 in das Register schreibe) das Character Rom - auch wenn der 6510 es erst ab $d000 sieht.
Der Zeichensatz ist 2KB groß... Wenn mein Proggy also mal um 2KB wächst, kann ich die Sprites hinten dran lassen... Derzeit muss ich sie halt nach vorne schieben.

Danke jedenfalls fürs Mitsuchen!

Ja aber mein Problem ist ja, dass ich eben keine 16384 Bytes für Sprites zur
Verfügung habe, sondern nur 64*64=4096...

Eben deswegen! Ein Hires C64-Screen hat 9 Kb, Lowres sogar 10 Kb, d.h. du kannst mit dem Screen und Character ROM nur noch 4-5 KB für Sprites verwenden. Dann ist das VIC II RAM aus. Die 16KB wären ein theoretischer Wert wenn man z.B. einen 2 KB großen Char-Screen verwendet, wobei das keinesfalls eine üble Idee bei dem Spiel wäre...

Ich will aber mehrere Sprites hinterlegen für verschiedene Bilder desselben
Sprites, also für die Sprite-Animation.

Ich weiß! Speicher kopieren dauert länger als das umstellen eines Hardware-Pointers, aber wie viele Animphasen braucht das Spiel?

Mir schwebt vor, den Kleinen (er ist 8) für Programmieren zu begeistern.

Sorry, aber Commodere C64 BASIC tut genau das Gegenteil von begeistern, deswegen steigen viele schnell auf ASM um oder lassen das coden und spielen Spiele

. Das schlechte C64 BASIC hat mich damals zu Sinclair getrieben.
Aber 8 ist ein Alter mo man sich noch gut anpassen kann. Das Spiel ist jedenfalls ganz nett. Habe es im vorigen Jahrtausend auf VCS2600 gespielt.

Wir brauchen also Sprites für
- 2 Flugzeuge
- 2 Springer
- 2 Plattformen
- Windfahne

Blöde Frage: Wieso Sprites für Plattformen?
Und Fahnen lassen sich als Char Bitmaps doch genauso gut realisieren, wobei nur das oberste Char verändert werden muss.
Beim C64 lassen sich übrigens Hires und Lores Sprites überlappen, damit kann man sie mit 2 Sprites wie Hires Multicolor erscheinen lassen.
2 Flugzeuge, 2 Springer zu je 2 Sprites=8 Sprites.

Die 16KB wären ein theoretischer Wert wenn man z.B. einen 2 KB großen Char-Screen verwendet, wobei das keinesfalls eine üble Idee bei dem Spiel wäre...

Ja, Wir bauen es in Blockgraphik... Wir definieren nicht mal den Zeichensatz um... Wir brauchen ja nur "inverse Spaces" für den braunen Boden

Ich weiß! Speicher kopieren dauert länger als das umstellen eines Hardware-Pointers, aber wie viele Animphasen braucht das Spiel?

Mal sehen... Noch nicht geklärt

.

Auch wenn wir es nicht brauchen:

Lowres sogar 10 K

? Wie kommst auf das? Wenn Du damit Multicolor meinst: Gleich viel Farbram/Screen wie Hires, oder?

Sorry, aber Commodere C64 BASIC tut genau das Gegenteil von begeistern, deswegen steigen viele schnell auf ASM um oder lassen das coden und spielen Spiele

Geh, ich hatte davor den ZX/81... 1 KB Ram (und da war der Bildschirmspeicher auch drin). Der C=64 war super komfortabel im Vergleich

Losgelöst davon war man beim ZX/81 seeehr schnell bei Assembler... Weil die CPU selbst das Videosignal erzeugte, war Basic bei weitem langsamer als am C64. Das Asse-Coden war auch umständlicher als beim C64... Das Programm packte man in REM-Zeilen. Jede konnte 32 Bytes oder so lang werden. Dann brauchtest einen JMP zur nächsten Zeile... Alles mühsam am Zettel ermittelt, weil für einen Assembler kein Platz im RAM war

Das schlechte C64 BASIC hat mich damals zu Sinclair getrieben.

Und mich hat die feine C=64 Hardware im Vergleich zum ZX/81 schwören lassen, nie wieder Sinclair zu kaufen

Im Ernst, ich halte den C64 für ein Topgerät in den Einstieg.... Eben weil er so einfach ist. Alles ist klar und übersichtlich, es gibt keine Problemfelder wie RaceConditions, ... (wenn wir mal Rasters aussen vor lassen).

Das Basic ist supereinfach (weil super limitiert), die Hardware nett ansteuerbar (zumindest SID und VIC), .... und man bekommt seeehr schnell Erfolgserlebnisse.
Einen Hintergrundschirm (oben blau, unten braun) hast in <10 Mins für den C64 mit FOR/NEXT/PRINT gebaut, bei einem Terminal müsstest Dich erst mal in Curses einarbeiten.

Unser Plan ist jedenfalls:
- BASIC zum einfachen kennenlernen
- Danach C mit cc65 um schnell eine sinnvolle Sprache zu haben.

Blöde Frage: Wieso Sprites für Plattformen?

Natürlich. Auch die Fahne könntest locker mit Blockgraphik machen. Dadurch, dass seeehr wenig bewegte Teile sind, könntest sogar alles mit umdefinierten Zeichen lösen... Wenn Die Flugzeuge halt um 1-7 Bit versetzt auch Platz im Character-Ram finden. Sprites sind halt super-nett weil super-bequem. Die Kollisionsabfrage kriegst auch gleich geschenkt... Drum Sprites.

Nett am Ziel (Sky Diver) ist auch, dass man recht schnell etwas basteln kann, was besser aussieht als am VCS... Gut fürs Selbstbewusstsein

. Ausserdem gibts für jede bei uns verwendete Plattform (PCs, Wii, Handies) einen C64-Emulator - man kann es also auch mitnehmen.

? Wie kommst auf das? Wenn Du damit Multicolor meinst: Gleich viel
Farbram/Screen wie Hires, oder?

Theoretisch nur... Auch wenn der C64 bei Lowres (Ja, Multicolor) euine globale Farbe erzwingt, so wird noch im Farbram eine Farbe pro Character abgespeichert. Ja, ich weiß dass der C64 ein getrenntes FarbRAM hat. Ich rechne es halt immer dazu, Koala-Bilder haben ja 10 kb.

Geh, ich hatte davor den ZX/81... 1 KB Ram (und da war der Bildschirmspeicher
auch drin). Der C=64 war super komfortabel im Vergleich

Ich schreibe aber nicht von dem ZX81 sondern von ZX Spectrum... 48KB RAM, sehr gutes BASIC mit Grafikbefehlen die man am C64 vermisst. Ich will aber nicht flammen

. Habe selber einige C64 da.

Das Asse-Coden war auch umständlicher als beim C64... Das Programm packte man
in REM-Zeilen. Jede konnte 32 Bytes oder so lang werden. Dann brauchtest einen
JMP zur nächsten Zeile... Alles mühsam am Zettel ermittelt, weil für einen
Assembler kein Platz im RAM war .

Ich habe das ZX ASZMIC ROM, das ist da viel bequemer, aber wie gesagt, der Spectrum ist mir lieber. Für den ZX81 habe ich aber auch 64 KB Erweiterung.

Einen Hintergrundschirm (oben blau, unten braun) hast in <10 Mins für den C64
mit FOR/NEXT/PRINT gebaut, bei einem Terminal müsstest Dich erst mal in Curses einarbeiten.

Beim Spectrum dauert das keine 2 Minuten sowas zu programmieren.

Unser Plan ist jedenfalls:
- BASIC zum einfachen kennenlernen
- Danach C mit cc65 um schnell eine sinnvolle Sprache zu haben.

Ja, ist eine gute Idee. Für den Spectrum gibt es auch das ANSI C und mit Z88dk, aber ich bevorzuge den Crosscompiler von Boriel, der das BASIC stark erweitert, z.B. um binäre Operationen. Übrigens plant Boriel ab release 2.0 auch andere Plattformen zu unterstützen, darunter den C64.

Sprites sind halt super-nett weil super-bequem. Die Kollisionsabfrage kriegst
auch gleich geschenkt... Drum Sprites.

Kollision der Fahnenstange braucht man nicht, und wenn der Bub programmieren lernen soll, sollte er auch die Tricks beherrschen. Aber am Anfang kann man es mit Sprites lösen und später optimieren.

Nett am Ziel (Sky Diver) ist auch, dass man recht schnell etwas basteln kann,
was besser aussieht als am VCS... Gut fürs Selbstbewusstsein .

Wenn es nicht so wäre, würde ich enttäuscht sein

Nur echte Hardware rult.
Es gibt da irgendwo eine C64 Programmierumgebung am PC...

Theoretisch nur... Auch wenn der C64 bei Lowres (Ja, Multicolor) euine globale Farbe erzwingt, so wird noch im Farbram eine Farbe pro Character abgespeichert. Ja, ich weiß dass der C64 ein getrenntes FarbRAM hat. Ich rechne es halt immer dazu, Koala-Bilder haben ja 10 kb.

Ich stehe gerade auf der Leitung:
Bei LowRes hast:
- 8KB Bildschirmspeicher für die 160x200 Punkte/2 bits pro Pixel.
- 1KB FarbRam
Der Zeichenalgo war so ca:
- "00" = Hintergrundfarbe
- "11" = Vordergrundfarbe
- "01" = 4 Bits aus dem passenden Byte aus dem Farbram
- "10" = 4 andere Bits aus dem passenden Byte aus dem Farbram

Bei HiRes hast:
- 8KB Bildschirmspeicher für die 160x200 Punkte/2 bits pro Pixel.
- 1KB FarbRam
Der Zeichenalgo war so ca:
- "0" = Hintergrundfarbe
- "1" = Vordergrundfarbe aus dem Farbram (1 Byte für 8x8 Pixel)

IMHO braucht LoRes dasselbe Ram wie HighRes

Beim Spectrum dauert das keine 2 Minuten sowas zu programmieren.

Ebenfalls ohne Flamen zu wollen: Farben am Spectrum sind _hart_ bei Graphik... Die Farbgestaltung mit dem brutalen Farbraster ist schlimm.... Das das Basic dafür am Speccy netter war, stimmt aber auch. Nur wer nutzt schon Basic? Praktischer fand ich da auf den Sinclairs schon den Z80. Vom Z80 zu 6502 wechseln ist mir vorgekommen, wie von einer Supermaschine auf ein Steinzeittrum zu wechseln

Kollision der Fahnenstange braucht man nicht, und wenn der Bub programmieren lernen soll, sollte er auch die Tricks beherrschen

Keine Frage. Derzeit brauche ich aber etwas, was _schnell_ klappt. Die Aufmerksamkeitsspanne ist da bei neuen "Spielsachen" gering. Beispielsweise Lego Mindstorms (mit 6 bekommen): 3 Tage Tag und Nacht genutzt, dann wochenlang weggeräumt

.
Wir brauchen also etwas, was täglich Fortschritte macht. Für die Fahne als Zeichen würde ich eine Datenstruktur anlegen, die einfach über den Bildschirm geschrieben wird... zB ein Array von char* pro Fahnenposition. Oder in Basic halt mit 2dimensionalen Strings arbeiten. Wenn wir das als Sprite lösen, brauchen wir mehrdimensionale Felder noch nicht kennen

. Ein weiterer Vorteil der Sprites ist, dass sich die 1:1 in C übernehmen lassen. Das Umlernen wird leichter. Alternativ könnte man die Fahne mit einem umdeklarierten Zeichen erzeugen. Das wäre auch einfach - dann ist sie aber arg klein.

Ausserdem ist ja im Auge zu halten, was er kann... Und das ist noch wenig... Es ist ja schon das Konzept der Variablen neu... Variable kennen sie ja noch nicht mal aus Mathe in der Schule

. Derzeit kann er
- NEW/CLR
- "normale"/nicht dimensionierte Variablen (Also X, X% und X$)
- GOTO
- IF/THEN
- LIST
- PRINT
- GET/INPUT
- RND(0)
- FOR/TO/STEP

Dringend benötigte Gschichten wie PEEK, POKE, AND, OR - oder auch nur die Binäraritmhetik - kann er noch nicht. Das werden wir uns am Wochenende noch ansehen.

Es gibt da irgendwo eine C64 Programmierumgebung am PC...

Wir werden dann eben cc65 am PC nutzen. Rennt (auch) unter Linux. Ist ein seeehr cleverer c-Compiler für diverse 65xx-Maschinen, hat einen mächtigen Assembler und Linker dabei, ... http://www.cc65.org/

Programmieren wird also bald aussehen wie es soll: Auf einem ASCII-Terminal (oder in einem x-Term) mit vim

13.01.2012, 07:40 Uhr - Editiert von kombipaket, alte Version: hier

IMHO braucht LoRes dasselbe Ram wie HighRes

Wie gesagt, theoretisch... Dann bräuchte man kein FarbRAM wenn es genauso viel wäre.

Farben am Spectrum sind _hart_ bei Graphik..

Bestreite ich auch gar nicht. Du hast Recht, Spectrum ist sehr limitiert, und nicht nur in der Hinsicht. C64 im Hires wäre ohne Sprites fast genauso schlimm.

Nur wer nutzt schon Basic?

Ich nutze es gerne und compiliere dann. Zeitkritische Routinen kann man immer noch mit InLine Assembler einbauen.

Keine Frage. Derzeit brauche ich aber etwas, was _schnell_ klappt. Die
Aufmerksamkeitsspanne ist da bei neuen "Spielsachen" gering. Beispielsweise
Lego Mindstorms (mit 6 bekommen): 3 Tage Tag und Nacht genutzt, dann
wochenlang weggeräumt .

Das ist bei Kindern normal, in dem Alter zumindest.

Alternativ könnte man die Fahne mit einem umdeklarierten Zeichen erzeugen.
Das wäre auch einfach - dann ist sie aber arg klein.

Man könnte auch 4 Chars dafür nutzen, dann ist sie groß genug.

Ausserdem ist ja im Auge zu halten, was er kann... Und das ist noch wenig...

Der junge Jedi Padawan lernt langsam von seinem Meister...

Derzeit kann er
- GOTO

Kein GOSUB/RETURN? sollte er als nächstes lernen.

- RND(0)

(0)?

- FOR/TO/STEP

Ohne NEXT wird daraus nichts

Und POKE und PEEK sollte er auch beherrschen. Das sind die wichtigsten Befehle auf dem C64.

Wir werden dann eben cc65 am PC nutzen.

Keine Sorge! Kannte ich bereits....

Wie gesagt, theoretisch... Dann bräuchte man kein FarbRAM wenn es genauso viel wäre.

FarbRam im Hires-Mode: 1KB.
FarbRam im MultiColour-Mode: 1KB.
Du musst mir noch erklären, wo da der Unterschied sein soll

Gosub/Return/Poke/Peek/... kommen eh als nächstes... Eines nach dem anderen. Nur nicht überfordern, vom leichten zum Schweren, ...

Du musst mir noch erklären, wo da der Unterschied sein soll

Beim zwischenspeichern der Daten im Speicher oder auf einem externen Datenträger. Ich weiß schon... Wird bei demn Spiel nicht benötigt.

Gosub/Return/Poke/Peek/... kommen eh als nächstes... Eines nach dem anderen.
Nur nicht überfordern, vom leichten zum Schweren, ...

Na ja, schwer sind diese nicht. Na dann hoffe ich dass ein großartiger neuer C64 coder da heranwächst

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung