Diskussion:Sprite

Dropbox-Links

Ist das wirklich gut, an vermutlich Personen hängende Cloud-Referenzen zu hinterlegen? Im Dropbox-Fall hab ich den Eindruck, dass die Personenbindung besonders stark ist und so etwas schnell mal in der "Luft" hängen kann. Aber vielleicht bin ich da zu skeptisch.

Kann man da nicht einen z. B. Github-Account erstellen (vielleicht sogar im Namen des C64-Wikis) und dort Images und Sourcen etc. hochladen? --JohannKlasek (Diskussion) 11:05, 18. Jun. 2022 (CEST)

Du hast Recht mit Deinem Einwand. Meine Dropbox-Links sind auch nur als vorläufig zu betrachten, bis eine Lösung für Downloads gefunden worden ist. Deinen Vorschlag mit Github finde ich sehr interessant. Wer will/sollte das dann (als C64-Wiki) einrichten? Dass Du hier keineswegs zu skeptisch bist, sieht man bei den Assembler-Befehlen, deren (privat zur Verfügung gestellte) Beispiele unter Weblinks nicht mehr funktionieren. --Petrus (Diskussion) 12:14, 18. Jun. 2022 (CEST)

Da es inzwischen möglich ist, ZIP-Dateien im Wiki hochzuladen, habe ich die beiden Dropbox-Links durch interne Links ersetzen können. --Petrus (Diskussion) 13:58, 21. Jun. 2022 (CEST)

Skeptisch? Das eine sollte nicht wegen etwas anderem relativiert werden (Whataboutism). Das Image bei den Assemblerbefehlen prüfe ich ja nicht ständig. Ich bin ja kein Robot, der durchs Wiki grast, das passiert alles immer im Anlassfall. Meine gefühlt nicht allzu lange zurückliegender Aufruf hat noch funktioniert ... Zumindest in der Waybackmachine gibt es noch eine Kopie vom 29.7.2016. Das reicht, die Kopie werd' ich mal ins Wiki einspielen, wenn jetzt die ZIPs nun gehen.
Generell wäre das natürlich ein typischer Fall für eine Github-Umsetzung, das wäre weit handlicher und wartungsfreundlicher, als das ziemlich starre ZIP-Archiv. Werde ich auf meine ToDo-Liste setzen. --JohannKlasek (Diskussion) 16:51, 21. Jun. 2022 (CEST)

Upload Beispiel

Hallo,

Ich würde gerne das Spriteprogramm als D64-Diskimage hochladen. Leider kommt dabei die Fehlermeldung D64 oder auch ZIP ist kein geeignetes Format. Also wie kann man ein solches C64-Diskimage hochladen? --Jodigi 07:08, 11. Jul 2006 (CEST)

Bei Klaws anfragen, ob er das ändert. --Joystick 11:34, 11. Jul 2006 (CEST)

Farbgebung

Bei "Farbgebung Multicolorsprites" widersprechen sich Beispielliste und Beispieltabelle. Ohne jetzt selber wühlen zu müssen: Wie isses denn nun richtig mit linkem und rechtem Bit? --GoDot 08:43, 1. Aug. 2007 (CEST)

Na, dann mach ich's halt selber... --GoDot 23:02, 1. Aug. 2007 (CEST)

Haste den Vertippen nun im Buch nachgelesen oder ausprobiert? --Jodigi 20:21, 3. Aug. 2007 (CEST)

Nee, ich hab in meine GoDot-Akten reingeschaut. Außerdem steht's (natürlich!) bereits hier im Wiki (unter VIC)! --GoDot 09:10, 4. Aug. 2007 (CEST)

Beispiel

Hallo,

das Beispiel, wie es angegeben ist, ist so nicht funktionsfähig auf dem C-64. Zeile 20 und 22 sind zu lang und führen zu einem Syntax-Error (Copy-Paste in den VICE). Des weiteren wird die Variable z und mehrere x- und y-Positionen der Sprites nicht initialisiert. Das führt bei Sprite 0 zu indem flackern zu Beginn der Animation.

Will man das Programm in einen C-64 Emulator Copy-Pasten passen die Groß-Kleinschreibung und die Umlaute nicht zur C-64 Basic Programmierung.

Ich habe das Programm einmal überarbeitet (kann man so in einen C-64 Emulator kopieren):

 1 rem bildschirmbereinigung
 2 printchr$(147): v=53248: f=peek(v+32): bg=peek(v+33)
 3 poke v+32,0: poke v+33,0
 4 rem speicherbereinigung für spritebereich
 5 for x=12800 to 12927: poke x,0: next x
 
 9 rem spritegenerierung
10 for x=12800 to 12881: read y: poke x,y: next x
11 poke 2040,200: poke 2041,201: poke 2042,201: poke v+21,7
12 rem multicolor fuer sprite 1+2
13 poke v+28,6: poke v+37,15: poke v+38,2
14 rem spritefarbe fuer sprite 0+1+2
15 poke v+39,7: poke v+40,8: poke v+41,6
16 rem spriteeigenschaften, hoehe, breite, bit 8 der x-position
15 poke v+23,7: poke v+29,7: poke v+16,1
16 poke v,200: poke v+1,133: rem x- und y-position fuer sprite 0
17 poke v+2,170: poke v+3,0: rem x- und y-position fuer sprite 1
18 poke v+4,0: poke v+5,115: rem x- und y-position fuer sprite 2

19 rem bewegung und farbaenderungen
20 z=0.0 : for x=200 to 1 step-1
21 poke v,x: z=z+0.61: poke v+3,z: poke v+4,(201-x)/2 : next x
22 poke v+16,0: poke v,255: m=peek(v+4)
23 for x=255 to 170 step-1
24 poke v,x: z=z+0.66: poke v+3,z: poke v+4,m+(256-x)/1.2: next x
25 for x=0 to 5: for y=1 to 255: poke v+37+x,y: next y,x
26 poke v+38,2: poke v+39,7: poke v+41,6
27 for y=1 to 65: poke v+40,y: poke v+37,y+10
28 for z=0 to 15: poke v+39,y: next z, y

29 rem warten, loeschen sprite 0 und ausblendung sprite 1+2
30 for x=0 to 3000: next x
31 for x=0 to 32: poke 12832+x,0: poke 12832-x,0
32 for y=0 to 100: next y,x: poke v+21,0
33 poke v+32,f: poke v+33,bg

39 rem sprite c 64 wiki de (einfarbig; sprite 0)
40 data 239,81,85,139,81,20,137,81,28,137,81,89,137,213,89,142,85,93,138   
41 data 95,85,138,91,85,238,91,85,0,0,0,0,0,0,0,0,0
42 data 0,199,0,0,231,0,0,164,0,0,180,0,0,151,0,0,180,0,0,164,0,0,231,0,0,199,0

44 rem multicolor-sprite linie (sprite 1+2)
45 data 0,255,255,255,170,85,170,170,85,170,85,170,85,85,170,85,255,255,255

Wenn das so genehm ist würde ich das Beispielprgramm wie oben angegeben ändern.

Grüße Jörg

Vielen Dank. Allerdings achte ich (und ein Teil der C64-Wiki-Autoren) nicht auf die Benutzerfreundlichkeit von Copy&Paste auf C64-Emulatoren am PC, sondern schön wie auch bei einem LIST ausgegeben auf Großschrift der BASIC-Befehle, damit die besser im C64-Wiki verlinkbar bleiben.

Auch beim Eingeben an einem realen C64 stellt sich die Frage, verwirrt Klein-Grossschrift den Programmieranfänger eher, der vielleicht nur in Grossschrift-Grafikzeichen das Programm mal kurz abtippt?

Die Zeilen 20 und 24 sind in der Tat etwas länger geworden, da aufgrund der Übersichtlichkeit einige Leerzeichen eingefügt wurden. Das habe ich mal abgeändert.

Z ist eigentlich 0, da durch RUN alle Variablen auf 0 gesetzt werden ! Und Z wird vor dem Erreichen der Zeile 20 auch nicht genutzt !

Das Programm kann auch als alternative hier in der Diskussion drin stehen bleiben. Alles kein Problem....--Jodigi 22:24, 31. Aug. 2011 (CEST)

Sprite/Hintergrund-Priorität

Hallo Leute, statt künstlich ein Beispiel für die Sprite/Hintergrund-Priorität mit Hilfe von "Giana Sisters" zu kreieren, könnte man ein echtes Beispiel aus "Mayhem in Monsterland" nehmen. Dort wurde das wirklich toll ein gearbeitet. https://youtu.be/ldo2ewLBt3Y?t=30m31s Zudem sollte man grundsätzlich einen kleinen Vermerk machen, aus welchem Spiel die Beispiel Sprites stammen (also hier "Giana Sisters"). Gruß Syncrow (Diskussion) 17:28, 4. Feb. 2018 (CET)

Overlay

Sollte man nicht mal erklären, was Sprite-Overlays sind? Die tollen Grafikmodi von Crossbow und Deekay (z.B. NUFLI) sind schließlich darauf aufgebaut! (Gibt's für die beiden noch gar keine Artikel? ) --GoDot (Diskussion) 23:53, 26. Nov. 2018 (CET)

Im Sprite-Artikel ist dazu IMHO unter Sprite Anzeigeprioritäten das Grundlegende gesagt. Einen eigenen Artikel Sprite-Overlays würde ich aber auch gut finden. Darin könnten dann auch diverse Beispiele mit Sprites und Grafik aufgeführt werden. --Petrus (Diskussion) 19:28, 6. Mär. 2021 (CET)

Positionierung

Vielleicht sollte man mal unter dem Punkt "Positionierung" eine Speichergrafik zeigen, auf der man sehen kann, wo im für Sprites zugänglichen Bereich der sichtbare Bildschirm liegt. Dann werden die Positionierungstabellen auch einleuchtender, finde ich. Sowas wie dies hier, nur besser leserlich und mit vielleicht weniger Infos (auf dustlayer.com ist ein gutes Bild):

--GoDot (Diskussion) 17:18, 6. Mär. 2021 (CET)

Ja, so etwas fehlt bislang (siehe auch vic-ii-for-beginners-beyond-the-screen-rasters-cycle. Sollte das aber nicht besser einen eigenen Artikel (z.B. Bildaufbau) bekommen, da es ja nicht nur die Sprites, sondern die gesamte Anzeige betrifft? --Petrus (Diskussion) 19:46, 6. Mär. 2021 (CET)

Wie ich gerade sehe, gibt es zu diesem Thema bereits die beiden Artikel PAL und NTSC --Petrus (Diskussion) 19:55, 6. Mär. 2021 (CET)

Ja, da habe ich das Diagramm her. Ich musste aber danach suchen, deshalb sollte es hier ebenso rein. Ist zu wichtig, m.M.n. --GoDot (Diskussion) 22:29, 6. Mär. 2021 (CET)

Um das Verhalten eines Sprites abzubilden, habe ich das Demoprogramm movesprite.zip (PRG und Acme-Quellcode enthalten) erstellt auf der Basis eines Programms von David Roberts aus GitHub. --Petrus (Diskussion) 22:23, 12. Mär. 2021 (CET)

Das Diagramm finde ich nicht nur ebenfalls z.T. schwer verständlich, es enthält auch Fehler: die Ausgabenhöhe ist mit 40 bzw. 38 statt mit 25 bzw. 24 Zeichen beschriftet. --Petrus (Diskussion) 10:55, 13. Mär. 2021 (CET)

Es gibt bessere, das ist wahr! Aber ein Diagramm an dieser Stelle wäre schon schön! --GoDot (Diskussion) 13:03, 13. Mär. 2021 (CET)

Klasse! Das ist genau das richtige Diagramm! --GoDot (Diskussion) 21:27, 13. Mär. 2021 (CET)

Sprite-Datenzeiger

Bei "Sprite-Datenzeiger" - "Speicheradressen" - "Anmerkung: Wird die Lage des Bildschirmspeichers verschoben, verändert sich auch die Lage der Sprite-Pointer!" könnte durchaus ergänzt werden, dass (natürlich) auch die VIC-Bank entscheidend für die tatsächlichen Speicheradressen ausschlaggebend ist. Das wissen Profis sowieso, aber Anfänger sicher nicht, und Fortgeschrittene übersehen eventuell solche "Kleinigkeiten". Also bitte entweder die Anmerkung ganz weglassen (Wiki nur für Profis), oder kurz ergänzen (Wiki auch für Anfänger/Fortgeschrittene). Danke!!

Die VIC-Bank wurde schon einen Absatz vorher und auch in dem Link hinter dem "Lage"-Satz erwähnt, aber ich hab's nochmal reingeschrieben. -- 1570 (Diskussion) 09:37, 20. Apr. 2023 (CEST)