Archiv der Kategorie: gamedev

Atari ST – keine Hardwaresprites aber Memory fürs PreRendering – das Display nur virtuell und schnell genug mit Tricks

Schreibe eine Antwort

Der Atari ST war bekanntlich ein 68k-Computer schnell zusammengebaut, nachdem Jack Tramiel (gerade von Commodore) gewechselt trotz Zusammenarbeit mit der Amiga Firma, den Zuschlag dann doch nicht gekriegt hat und der Amiga an Commodore ging. Durch die sehr schnelle Entwicklung war der Atari ST ein richtiger Computer. Er bestand aus einem Prozessor und viel RAM. Ohne Hardware-Unterstützung mussten alle Sprites in Echtzeit berechnet werden. Darum gab es eher wenige davon. Bis ein Kniff auftauchte – man konnte diese Sprites ja vorberechnen. Das Problem ist nämlich auch hier: Der Screen ist in 8Pixel eingeteilt, man muss also Pixel über diese Byte-Grenze bewegen oder in Assembler „Rollen/Shiften“ und den überschüssigen Pixel dann im wieder im nächsten Byte einfügen etc. Ein komplexes und vorallem rechenzeitlastiges Problem. Da hilft dann eben alle 16 Verschiebungen schon vorher zu machen und einfach die geeigneten Blöcke zu kopieren bzw. zuerst die Maske auschhneiden und den Rest darüber legen. Und in diesem Bereich ist der 68k schnell mit movem- und co. Und macht damit fast die Vorteile des Blitters des Amiga wet..

Vereinfacht sieht dies Folgendermassen aus. Das wäre eine monochromer Screen (nicht erklärt: 16 Farben werden in 4 Layern untergebracht – Bitplanes):

Anbei sieht man eine solche automatisch generierte Masse von 16 x 2er Bläcken und daneben die Maske. Aus dem Spiel TheHolyCube (Atari ST) extra visualisiert, da die Daten nicht so nebeneinander liegen.
Damit erreicht man relativ einfach 32 * 16×16 Sprites pro Frame.

Weiterlesen →

Blitter die Datenschleuder – das Beast, Herzstück des visuellen Amigas [wird upgedatet]

Schreibe eine Antwort

Der Blitter (https://de.wikipedia.org/wiki/Blitter_(Amiga)) ist einer der CustomChips, die den Amiga einzigartig gemacht haben im Homecomputerbereich. Das Herzstück des Amigas der 68000er Prozessor von Motorola ist zwar schnell und mächtig und einfach zu programmieren. Er ist aber – das zeigt der Atari ST – am Anschlag, wenn es darum geht Games mit vielen Objekten zu handeln.

Anders der Amiga – er hat neben peinlichen 8 Sprites – Sonderchips – wie später alle Computermodelle. Und der mächtigste unter ihnen ist der Amiga-Blitter.

Er ist in der Lage grosse Blöcke zu kopieren und zu kombinieren. Dabei meint man mit Blöcken nicht etwa rechteckige Blöcke auf einem Blatt sondern Speicherblöcke also hintereinanderliegender Speicher. Dies ist eine wichtige Einschränkung, was die Programmierung auf Hardwareebene (Assembler), sehr mühsam macht.

Der Blitter besteht prinzipiell aus 4 Kanälen (vgl. DMA), die kombiniert werden können. Die Kombinationsmöglichkeiten lassen sich hier ausprobieren:
http://deadliners.net/BLTCONCheatSheet/index.html

Im obigen Bild sieht man die Möglichkeit der sogenannten Blobs eine Art „HardSoftsprites“. Das heisst die Kombination eines Hintergrunds mit einer Maske und einem Objekt. Dazu braucht der ABlitter das gesamte Potential. Es gibt aber auch die Möglichkeit in der Kombination Dinge zu füllen, zu kopieren etc.

Die Möglichkeiten sind teilweise auch völlig unsinnig und in der Programmierung ist es denn auch schwierig genau zu verstehen, was passiert. Der Chip ist eine Art Black Box.

Weiterlesen →

Sprites, DoubleBuffering oder der Amiga mit Blitter ohne DoubleBuffering und mit

Schreibe eine Antwort

(Interaktive) Echtzeitgrafik beginnt (vereinfacht) zu flackern, wenn die Hardware nicht mehr schnell genug ist, die Grafik schneller als der Rasterstrahl zu zeichnen.

Double-Buffering

In diesem Fall benutzt man zwei Screens, die man hin- und herzeigt, um auf dem nicht-gezeigten Screen zu zeichnen. Mehr dazu findet sich hier > Dies ist ein Verfahren, das bei einem Grossteil der Anwendungen eigentlich keine Rolle spielt, da vieles Tools sind.

Games und Double-Buffering

Anders im Gamebereich – hier gilt das Flackern als „Sünde“ (Todo: Gibt es Spiele, die mit grossflächigem Flackern arbeiten als Gamemechanik? Mission Impossible?). Denn – es zerstört offensichtlich die ‚Immersion‘ und deutet auf ein techniches System hin. Es wird als Störung gedeutet.

Weiterlesen →

Extreme Programming avant la lettre – GameDev 1980+ zu Hause, in Clubs und an Demoparties

Schreibe eine Antwort

Extreme Programming ist eine Methode der agilen Entwicklung. Zwei Leute sitzen da und entwickeln gemeinsam.

Nach einem Gespräch mit Philip Jesperson (Entwickler von Supaplex) und auch zu sehen im „Capt der digitalen Hoffnung“ (SRF 1987) ist wieder klarer geworden: Extreme Programming, Developing und GameDesign war in der Gründerzeit der digitalen Revolution (Homecomputer) in Sachen Games vermutlich Teil des Alltags. Die Gründe sind dafür vielfältig aber auch klar: Computer waren rar. Also hatte nicht jeder einen, den richtigen (etwa einen Amiga) und schon gar nicht zwei. Notebooks waren sündhaft teuer.

Entwickeln war also oft nur zusammen möglich. Und so trafen sich die Entwickler* dann auch bei sich zu Hause oder im ComputerClub oder eben auch an Parties, die quasi viele Funktionen eben auch die soziale Komponenten per se mitbrachten. Dabei lernten die Personen – im Diskutieren von Code und „Wie machst du das“ – auch über diese persönlichen Kontakte, das gemeinsame Entwickeln. Dabei war vermutlich – so zumindest die Beispiele – die konkrete Nähe geografisch wichtig.

Dabei ist der Unterschied zwischen Cracking, Demoscene und GameDesign nicht riesig – den wie „man es“ technisch fertig brachte, waren ähnliche Challenges.

Jenseits der Konsumenten*perspektive oder die brutale Produktions- und Entwickler*perspektive

Schreibe eine Antwort

Wer sich Games anschaut eines Computersystems ist meistens erfreut, was es da alles gibt. Da denkt der Recipient: WOW – Unglaublich. Gerade wenn eine Selektion so visuell ist wie die Nachfolgende.

Dabei linearisiert natürlich das Medium Film die interaktive Erfahrung und die Spielmechanik oder das Gameplay spielt keine Rolle. Das ist letztlich die Sicht des Konsums, der Konsumenten. Und damit reproduziert sowohl die Fans, Interessierte Spieler und ganze Teile der Wissenschaft nur den Markt.Beziehungsweise nicht mal den Markt, denn da wäre auch zu nennen, wieviel die Spiele gekostet haben. Meist wird geurteilt ohne jeglichen Bezug einfach nur absolut. Selbst die Entsehungszeit wird oft gnadenlos ausgeblendet,

Die Produzenten*- und Entwickler*-Perspektive

Noch viel schlimmer ist allerdings nur das Betrachten des Endproduktes. Dies ist auch der Marktlogik geschuldet. Der Rezipient*/Spieler* ist ja der Käufer*, der Herrscher über das erstandene Produkt. Wie dieses entstanden ist und zu welchen Kosten auch menschlichen interessiert bis heute in der Gameindustrie niemanden. Das Produkt ist transparent im Informatik-Sinn: Es spielt keine Rolle wie. Deswegen fehlen bis heute im Gamebereich jegliche Labels. Dabei ist es essentiell unter welchen Bedingungen Games entstanden sind.

Dabei spielt es massiv eine Rolle unter welchen Bedingungen, Zeit, Geld, Teams ein Spiel entstand. Die Würdigung des Geleisteten ist nur so möglich und dies ist Teil vom Designprozess. Und hier zeigt sich denn auch bis heute von was Gamer* profitieren. Viele der oben genannten Spiele sind nur durch ausserordentliche Nutzung überhaupt möglich geworden. Das bedeutet letztlich – vermutlich anders als im Consolenbereich – unter massiven Anstrengungen und menschlichen Ressourcen. Teilweise vermutlich jenseits von irgendwelcher möglicher Rendite und angenehmen Arbeitsbedingungen. Nicht dass dies heute anders wäre, wo vorallem der Content so erarbeitet wird. Aber es ist auch diese Spur, die es offen zu legen gilt, um mit dem ’schönen‘ Spiel richtig umzugehen und es einordnen zu können.

Dabei muss jedem* klar sein, so einfach und lustig wie die Leute hier erzählen sind diese Tricks nicht zu implementieren. Auch dies gehört zum Habitus des Geniekults den Aufwand, die Irrungen nicht klar zu machen.

Hier ein paar Tricks ohne die viele Amiga Games etwa nicht möglich wären:

https://codetapper.com/amiga/sprite-tricks