Diskussion:Sprite (Computergrafik)

URL

www.gifsyndicate.com/ is now gifsyn.electricpopsicle.com

---

Ich glaub, die englische Wikipedia sagt da was anderes (und da Sprite ein englischer (aus dem Englischen) Begriff zu sein scheint...). --Alien4 04:36, 9. Jun 2006 (CEST)

Was meinst du damit genau? en:Sprite (computer graphics) sagt doch ziemlich genau das Gleiche; mit dem Unterschied, dass dort mehr die 3D-Sprites betont werden, die man allerdings eher als Textur bezeichnet. Dieser Artikel beschreibt IMHO besser, was ein Sprite nach der ursprünglichen Bedeutung ist. --Christoph 09:54, 9. Jun 2006 (CEST)

Ich dachte nur, im ersten Satz der englischen Einleitung steht nichts von (zwingender?) (Spezial/Grafik?)Hardware. Es sagt nur: ein Bild(chen)(auschnitt) -> eingefügt in einem grösseren Bild ("Szenerie"). Dass (heute?) die Meisten ( ... Amiga und auch noch ältere?; Computerspiele usw.) mit "spezieller" Grafikhardware ((noch?) bessere Performance) arbeiten, ist das wirklich zwingend, dass man überhaupt von "Sprite" sprechen kann? Meiner Meinung nach wird das in der deutschen Einleitung (fälschlicherweie?) suggeriert. --Alien4 03:33, 25. Jun 2006 (CEST)

Noch älter als Amiga: C64, mit Spezial-Sprite-Hardware. Ich denke, heutzutage geht die Unterscheidung so:
Sprite = Spezialhardware mit in der Tat eingebautem Performance-Vorteil;
Software-Sprite (bei Amiga: BOB oder auch Shape = dasselbe pur in Software und dadurch langsam.
An fehlenden Begriffen sollte es also nicht scheitern :-).
Andererseits sagt der englische Text eindeutig, der Begriff Sprite sei (dort?) mittlerweile auch auf die Software-Variante übergegangen. Da halte ich mich dann doch lieber raus, aber es könnte doch auch sein, dass man hierzulande nicht jeden merkwürdigen Trend aus USA mitmacht... --PeterFrankfurt 22:10, 25. Jun 2006 (CEST)

OK, für mich fehlt wohl nur noch ein kurzes Wort (Hinweis) in der Einleitung. Aber ich bin wohl ein Sonderfall, der gerne (alles) (Haupt)Wissen (hier vielleicht für alle anderen nicht der Fall) schon in der Einleitung kurz aufgeführt sieht, um nicht im "Wust" suchen zu müssen. (Vielleicht manchmal nett, in der Diskussion kurz darauf hinzuweisen -> Artikel geändert - ich weiss, ich bin sehr bequem/faul.) --Alien4 17:17, 29. Jun 2006 (CEST)

Das ist so nicht ganz richtig: ein BOB ist ein sog. Blitter-Object. Der Blitter ist sehr wohl Hardware, nämlich ein Teil in der Speicherverwaltung (MMU) der das Verschieben von ganzen Speicherbereichen (eben auch innerhalb des Grafikspeichers) extrem schnell, effizient und autonom von der CPU beherrscht. BOBs sind somit eigentlich hardwarebeschleunigte Shapes, wenn man so will. Shapes indes müssen komplett vom Betriebssystem und somit von der CPU erzeugt und angezeigt werden, daher sind diese nur sehr langsam und mühselig zu programmieren. - Tom Knox 20:09, 29. Jun 2006 (CEST)

(Wage ich vielleicht jetzt doch zu fragen, was "Sprite" eigentlich ist? Jetzt unbedingt mit "Spezial"hardware (damit man überhaupt von "Sprite" sprechen kann), oder eben jetzt ("Spezial"hardware) - wie (schon?) gesagt, heute wohl eher nur noch "historisch - doch nicht unbedingt nötig? Bräuchte es vielleicht eine Mehrheiten-Abstimmung deutschsprachiger Computer-Leute - oder lassen wir es lieber ... Duden-Rechtschreibreformen?) --Alien4 03:14, 2. Jul 2006 (CEST)

Sprites werden immer von einer speziellen Hardware innerhalb eines Grafikprozessors bei der Bilddarstellung auf dem Bildschirm von diesem als Overlay über allem anderen darzustellenden Bilddaten dargestellt, und das völlig unabhängig von der CPU. Für ein Sprite wird hierzu ein eigener Speicherbereich benutzt, der auch nur für das jeweilige Sprite verwendet werden kann. In der Software sagt man dem Grafikprozessor nur noch, an welcher X-Y-Koordinate er welches Sprite anzeigen soll. Ein BOB ist ein im Grafikspeicher vorhandener und sichtbarer Grafikbereich, der von einem Blitter als Bestandteil einer Speicherverwaltungseinheit (MMU) sehr schnell von A nach B kopiert wird. Ein Shape ist das selbe, nur eben langsam in Software realisiert. Simpel ausgedrückt. Ist der Unterschied nun noch immer nicht klar? - Tom Knox 09:56, 2. Jul 2006 (CEST)

Sprites können durch Hardware unterstützt werden - müssen es aber nicht - in ersterem Fall spricht man dan von einem Hardware-Sprite so sie wie der C64 z.B. kannte. In der Tat lassen sich Sprites auch per reiner Softwarelösung erzeugen und es verwundert mich es, das selbst auf der englischsprachigen Wike keiner so richtig...naja. Der Unterschied von einem Shape zu einem Sprite klärt das Ganze auf: Wir haben eine Graphik auf der sich zu bewegende Objekte befinden sollen. Bei einem Shape werden diese Graphikobjekte VOR, bei einem Sprite WÄHREND der Darstellung dem Bild hinzugefügt. Ein Shape wird dabei in den Displaybuffer hineinkopiert - ein Sprite nicht. Das Ausgabebild mitsamt der Sprites gibt es nirgendwo im Speicher, auch nicht im aktiven Bildpuffer - bei Shapes jedoch sehr wohl. Ist der Mauszeiger ein Sprite, kommt er bei einem Screenshot nicht mit. Der größte Vorteil von Sprites ist, das man auf das Retten und Restaurieren des Hintergrundes vollständig verzichten kann - die C64 Hardware machte nichts anderes. Erreichte der Rasterstrahl die Stelle an der das Sprite aufgegeben werden sollte, dann wurde nicht der Bildpuffer, sondern der Spritebuffer als Quelle verwendet - der Ptr im Bildpuffer jedoch analog weitergezählt. Während beim C64 einem das die Hardware abnahm, musste man bei anderen Systemen händisch eingreifen. Was die Pixelinformation im Spritebuffer nicht gesetzt, wurde der Bildpuffer genommen. Sprites sind Bildobjekte, die im Gegensatz zu Shapes nicht in den Bildpuffer kopiert werden, sondern lediglich bei der Ausgabe hinzugefügt werden. Sprites haben auf der alten PC-Architektur kaum Bedeutung, da die Umsetzung nicht ganz einfach ist. Dies lag insbesondere daran das es nicht ganz einfach war aufgrund der entkoppelten Graphikkarte an einen Rasterinterrupt heranzukommen. Dazu kam noch das verschiedene PC's verschiedene Graphikadapter hatten - beim C64 gab es nur eine Hardware. Bei langsamens PC's (8086 und 80286) war die Refreshrate zu hoch um angemessen reagieren zu können, ab dem 386er war die Rechenleistung hoch genug um auf Sprites vollstädnig verzichten zu können.

Ja, aber wie willst du denn bei einem PC von einem Pixel zum nächsten während der Bildausgabe per reiner Software auf die Spritedaten umschalten? Das läuft nicht. Selbst wenn es einen Rasterinterrupt gäbe, muss zu Anfang einer Interruptroutine erstmal die ganze Registerei und sonstwas auf den Stack, bevor die eigentliche Arbeit losgehen kann, dann ist der Rasterstrahl aber schon einige Pixel weiter! Und selbst wenn man es mit Einrechnung so einer Vorlaufzeit packt, das erste Pixel zum richtigen Zeitpunkt einzusteuern (wo speichert man das bei einer Grafikkarte überhaupt hin, hat die ein Register für den Pixelausgang, für ggf. alle 24 Bit davon?), weiß ich nicht, wie man im exakten Pixeltakt die nächsten dann auch noch schaffen will. Keine Chance in meinen Augen für Sprites per SW auf dem PC. Es sei denn, man kann da innerhalb einer Grafikkarte was drehen, die werden ja auch immer intelligenter, aber dann sind wir schon wieder fast bei den Hardware-Sprites. --PeterFrankfurt 02:17, 4. Dez. 2007 (CET)

Bei einem PC kommt es erst einmal darauf an welche Grafikhardware verwendet wird. Grundsätzlich reden wir von den PCs vor rund 15 Jahren - auf aktuellen Graphikadaptern sind Sprites kein Thema mehr - heute gibt es andere Konzepte. Das Verfahren mit dem Rasterzeileninterrupt funktioniert beim PC nicht - zumindest nicht in dieser Form. Acceleratorkarten boten jedoch die Möglichkeit mehrere Speicherseiten der Graphikkarte zu verknüpfen. Auf der einen Speicherseite war der Hintergrund, auf der anderen die Sprites. Nun wurde die VGA so programmiert, das zuerst die Hintergundseite und dann die Spriteseite betrachtet wird. Man muss keinen Hintergrund retten und Sprites dürfen beliebig groß werden und es dürfen beliebig viele sein. Thomas Merbold 18:44, 31. Aug. 2010 (CEST)

Und diese Speicherseiten werden von der Ausgabeelektronik dann überlagert? Mit den Sprites immer im Vordergrund? Hört sich interessant an, war mir bisher vollkommen unbekannt. Kann man darüber irgendwo was nachlesen? --PeterFrankfurt 02:57, 1. Sep. 2010 (CEST)

Streichung

„(Beispiel: C64, Breite und Höhe der Sprites fest)“ – Die hier zu lesende Aussage stimmt zwar, im Kontext ist sie aber falsch gewesen, weil die Sprite-Daten per DMA aus dem Grafikspeicher (=Hauptspeicher) geholt werden und nur die Positionen in Hardware-Registern stehen. -- Pemu 01:08, 19. Sep 2006 (CEST)

Trotzdem ist beim C64 im Gegensatz zum Amiga alles fest, und diesen Gegensatz sollte man schon aus Anschaulichkeitsgründen drin lassen. --PeterFrankfurt 02:00, 19. Sep 2006 (CEST)

Jetzt verstehe ich erst, was Du meinst. Ich habe das mal präzisiert, indem ich zwischen „Grafikdaten“ und „Steuerdaten“ unterscheide. Ansonsten finde ich es nicht notwendig, viele (zum Thema nichts beitragende) Amiga-Besonderheiten zu erwähnen. Auch die Details zu C64 und Amiga sollte man mMn aus dem Artikel herauslassen. Ich würde für eine Tabelle plädieren, in welcher die Eigentümlichkeiten der einzelnen Rechnersysteme aufgeführt werden. Einträge:

Modell | Grafikprozessor | Größe eines Sprites   | Auflösung                            |Anzahl der Sprites                                   | Bemerkungen.

C64    | VIC 6569 (?)    | 24 × 21               | Hires, 1 Farbe; Multicolor, 3 Farben | 8, vertikale Mehrfachnutzung per Raster-IRQ möglich | Verdoppelung der Größe bei Hlabierung der Auflösung in X- undoder Y-Richtung
Amiga  | OCS             | 16 × (2 bis 312)      | Lores, 3 Farben (?)                  | 8, vertikale Mehrfachnutzung per Copper möglich     |
Amiga  | ECS             | ?
Amiga  | AGA             | (16/32) × (2 bis 312) | Lores, Hires, 3 Farben (?)           | 8, vertikale Mehrfachnutzung per Copper möglich     |
...

So in der Art.

-- Pemu 03:48, 23. Sep 2006 (CEST); 01:40, 24. Sep 2006 (CEST)

Ja, schön. So ist es deutlich, find ich gut. Die Feinheiten bei ECS habe ich aber leider auch nicht parat. --PeterFrankfurt 15:22, 23. Sep 2006 (CEST)

"Es gibt drei Verfahren für Softwaresprites"

Da ist der Schreiberling wohl von seinem Wissensstand ausgegangen! Ich kenne mindestens 2 weitere Verfahren, die insbesondere für den VGA-Modus mit 256 Farben sehr häufig angewandt worden. Das meistgenutzte war eine Art RLE-Kompression. Es wird ein Byte mit der Anzahl transparenter Pixel gespeichert und diese bei der Anzeige übersprungen. Darauf folgt ein Byte mit der Anzahl der "befüllten" Pixel und diese werden dann angezeigt, danach folgt wieder ein Transparenzzähler usw. Das andere Verfahren waren kompilierte Sprites. In einem CPU-Register steht ein Zeiger auf eine Adresse innerhalb des Ausgabebildschirms berechnet anhand der Position (X,Y) des Sprites. Die befüllten Pixel werden mittels MOV-Anweisungen kopiert, für die transparenten Pixel entfallen diese MOVs. Beide Verfahren sind sehr technisch und für Laien sicher nicht einfach zu erläutern; dies gilt aber auch für die anderen genannten. Da beide von mir genannten Varianten eine recht hohe Verbreitung in den frühen 1990er Jahren hatten, sowohl am PC als auch am 68K-Mac, passe ich die Überschrift der Aufzählung an. (nicht signierter Beitrag von 178.8.86.239 (Diskussion) 16:36, 21. Feb. 2012 (CET))

Eine einfache Erklärung für Softwaresprites muss ja nicht zwangsläufig mit technischen Details den Laien überfordern, es genügt doch schon ein einfaches Verfahren(es gibt bestimmt mehr als nur drei) aufzuzeigen.

--Softwaresprites für 32 Bit Farbmodi---

Zum Beispiel für Videomodi mit 32 Bit Farben(Je 8 Bit für R,G,B,X) kann man zunächst ein Bild mit 32 Bit-Farben je Pixel in einem reservierten Speicherbereich genauso auspacken, so als wenn es in den linearen Framebuffer zur Anzeige gebracht werden soll. Danach kann man den reservierten Speicherbereich 32 bitweise auslesen und wenn dort eine Farbe enthalten ist, dann kann man damit eine Tabelle anlegen, wo man die relativen Adressen und die Farben einträgt. Unsere Tabelle enthält dann die relativen 32 bit Adressen und die 32 Bit-Farben von jedem farbigen Pixel des Bildes. (Die einzelnen Farbpixel können dabei auch unzusammenhängend sich über den gesamten Bildbereich verteilen und erstrecken und brauchen auch keine besondere Form, oder bestimmte Ausmasse in der Größe haben.)

Nun kann unser linearer Framebuffer mit einem Hintergrund-Bild befüllt werden. Bevor wir nun unser Softwaresprite zum Bildschirm bringen holen wir aus unserer Tabelle die jeweilige relative Adresse und addieren zu dieser Adresse die lineare Adresse des Framebuffers + die Bild-Position dazu, wo unser Sprite angezeigt werden soll. Mit dieser Adresse holen wir nun die jeweilige Hintergrund-Farbe und legen mit diesen Adressen und den Farbwerten eine neue Tabelle an, um den Hintergrund später auch wieder restaurieren zu können.

Nun können wir aus unserer ersten Tabelle jeweils die Farben für unser Sprite holen und aus der zweiten Tabelle die Adressen von der Position, wo unser Sprite angezeigt werden soll. Nun brauchen wir nur noch mit den Adressen die Farbpixel in den linearen framebuffer schreiben.

----

Optimierung: Um Objekte über den Bildschirm zu bewegen, die ggf. auch grösser sind als die Auflösung des verwendeten Videomodes empfielt es sich ein double, oder triple buffering zu verwenden, wobei die jeweilige Startadresse des angezeigten Bildbereiches im linearen Framebuffer im Wechsel ausgetäuscht wird und man immer nur den Inhalt des gerade nicht angezeigten Bildspeichers beschreibt und wobei der Wechsel der Anzeige mit dem Rasterstrahl syncronisiert wird, damit unser Sprite im gesamten Bildbereich auch flimmerfrei und ohne ein Tearing angezeigt werden kann.

Aber auch ohne ein Buffering sollte das Auslesen der Pixel direkt aus dem Bildspeicher bestenfalls vermieden werden und anstelle dessen sollte man eine Kopie des Bildinhaltes im RAM-Speicher auslesen und auch dort das Bild komplett zusammenstellen und von dort zum Bildspeicher als Ganzens in einem "Rutsch" kopieren. Weil der Bildspeicher wurde nur für das Beschreiben optimiert und das Auslesen aus dem Bildspeicher vollzieht sich um ein Vielfaches langsamer. Mit so einer Kopie vom aktuellen Bildinhalt braucht der Hintergrund von unserem Sprite nicht mehr in eine Tabelle gerettet zu werden, anstelle dessen können wir den Hintergrund nun aus diese Kopie zum Restaurieren verwenden. Dafür brauchen wir uns nur die vorherige Position(bzw. dessen relative Adresse) unseres Sprites zu merken und daraus die Position innerhalb der Kopie berechnen.

Ich hoffe das diese einfache Erklärung auch technische Laien noch nicht überfordert. Oder was meint ihr dazu?

Dirk (nicht signierter Beitrag von 78.54.138.217 (Diskussion) 13:02, 17. Jan. 2014 (CET))

Äh, mit Verlaub halte ich das für schwerer leserlich als den aktuellen Artikelzustand. Es ist auch länger, ohne dass es dadurch einfacher würde. --PeterFrankfurt (Diskussion) 05:25, 18. Jan. 2014 (CET)

Im Artikel wird es zwar erklärt, wie man transparente Bildpunkte im Sprite berücksichtigt, aber es wird doch gar nicht richtig aufgezeigt, welche Schritte nacheinander nötig sind, um ein Softwaresprite zum Bildschirm zu bringen. In meinem Beispiel wird es in wenigen Sätzen schon beinahe vollständig aufgezeigt, wie ein Softwaresprite zum Bildschirm kommen kann und es wird dadurch einfacher genau diesen Vorgang zu verstehen. Im Artikel fehlt dieser schrittweise Ablauf. Stattdessen werden dort nur transparente Bildpunkte im Sprite berücksichtigt, die in meinem Beispiel einfach unberücksichtigt bleiben können.

Auch sind es zwei unterschiedliche Verfahren deren jeweiligen Beschreibung einen anderen Ansatz verfolgen. Das von mir aufgezeigte Verfahren ist ohne diese spezielle Berücksichtigung von transparente Bildpunkte im Sprite einfacher gestaltet und damit ja wohl auch leichter zu verstehen.(Über die Wortwahl und den Statzbau in der Erklärung darüber kann man ja gerne streiten.)Der Längenvergleich für die Erklärung hinkt dann aber auch noch etwas, wenn im anderen Verfahren diese schrittweise Erklärung, wie ein Sprite zum Bildschirm gelangen kann, noch unvollständig ist und fehlt.

Wie eine Komprimierung die Anzeige beschleunigen soll, das wird auch nicht näher erklärt, nach meinem Verständniss verzögert es doch nur die Anzeige, weil die Daten dann ja auch noch zusätzlich ausgepackt werden müssen. Ein wesentlicher Unterschied zwischen den Verfahren ist aber der Speicherbedarf. So wird in dem von mir aufgezeigten Verfahren für jeden einzelnen Pixel in der Sprite-Tabelle für die Adresse 4 Bytes und für die Farbe weitere 4 Bytes, zusammen 8 Bytes je Pixel verwendet, womit ein erheblicher Platzbedarf entsteht. Allerdings ist die Anzahl der verwendbaren Farben bei Bildmodi mit 24/32 Bit auch höher, als nur mit 4 Bit, oder 8 Bit-Farben.

Dirk

Tut mir leid, meine Augen und mein Lesezentrum sagen mir was anderes. Außerdem ist das alles müßig, denn der Artikel geht hauptsächlich über Hardware-Sprites, und die Software-Sprites sollten eigentlich nur so am Rande miterwähnt werden und - zumindest ursprünglich - gar nicht bis ins Detail erläutert werden. --PeterFrankfurt (Diskussion) 03:02, 20. Jan. 2014 (CET)

Von "bis ins Detail erläutert werden" war ja auch gar nicht die Rede, sondern nur darum eine grobe Umschreibung der wenigen Schritte aufzuzeigen, die für Softwaresprites nötig sind, um sie auf dem Bildschirm anzuzeigen. Im Falle ihre Augen etwas anderes lesen, dann zeigen sie doch bitte mal die Stelle, woher sie dieses "bis ins Detail" entnommmen haben.

Ich meine so eine grobe Umschreibung macht mehr Sinn als transparente Pixel zu behandeln, die niemals zur Anzeige gebracht werden und die auch nicht wirklich zum sichtbaren Sprite mit dazu gehören. Im Artikel werden diese Details ja schon näher behandelt, obwohl in diesem Abschnitt es weder erlautert wird, wie so ein Sprite zum Bildschirm gelangt, noch das diese detailierte Behandlung von transparenten Pixels überhaupt nötig ist, um eine Softwaresprite anzuzeigen. Für "nur am Rande miterwähnt werden" geht der Artikel aber schon gewaltig ins Detail, wenn auch nur unwichtige Belange aufgezeigt werden, die mit einem Sprite nur entfernt am Rande etwas zu tun haben.

Müßig ist es ihre Verdrehung von Tatsachen zu lesen, wenn so getan wird als wenn im Artikel es noch gar nicht ins Detail gehen würde und meine nur grobe Beschreibung der nötigen Schritte für die Anzeige am Bildschirm, als schon zu detailiert darzustellen. Lieber Peter Frankfurt was möchtest sie damit eigentlich genau bezwecken und was tut ihnen daran eigentlich Leid? Im Falle ihnen das Verständniss dazu fehlt, wie wäre es dann wenn sie sich vorher um dieses nötige Verständniss bemühen, als nur ihr mangelndes Verständniss über eine grobe Umschreibung hier zu beklagen? Gerne kann ich ihnen auch noch detailierte Angaben für den schrittweisen Ablauf, des von mir aufgezeigten Verfahrens zukommen lassen, im Falle ihnen die bisher nur grobe Umschreibung davon noch zu oberflächlich und zu unpräzise erscheint.

Dirk (nicht signierter Beitrag von 85.177.156.109 (Diskussion) 09:01, 20. Jan. 2014 (CET))