Archiv der Kategorie: demoscene

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

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

Demos – Einzelanfertigungen [Kurznotiz]

Demos sind letztlich – zumindest für 1980-1993 – spezialisierte Einzelanfertigungen. Sie sind mehrheitlich – so zumindest die Einsicht Einzelprogrammierungen, weil nur dadurch es möglich ist, das Maximum aus der Hardware herauszuholen oder anders gesagt: Es muss mehrheitlich Hardware nahe sein, um überhaupt mit Tricks das ganze Potential herauszuholen. Dadurch verschliesst sich eine gewisse Verallgemeinerung in Richtung komplexeren Frameworks.

Selbstverständlich ist dies im Crackerbereich nicht ganz so gelaufen, hier scheint es zumindest, dass so etwas wie Frameworks entstanden sind. Eine ähnliche Situation wie wir sie auch im Gamebereich dieser Zeit sehen bzw. etwas was noch genauer untersucht werden muss. Denn auch hier enstanden Frameworks für Games.

Demoscene und/vs GameDesign 0.1 [Wird überarbeitet]

BereichDemosceneDemo-&GameDesignGameDesign
Entwickler*
Motivation
SeizeCoding (vorallem am Anfang 8Bit)
Zeigen, was möglich ist
Challenge / Konkurrenz
Community
Community um einen Computer herum (Idenität)
Kontrolle
Freizeitbeschäftigung unter Kollegen
Credits
SeizeCoding
SeizeDesigning
SeizeCoding (vorallem am Anfang 8Bit)
SeizeDesidning (bis heute)
Identitätsstiftend und Challenge gegen andere Platformen (Bsp. Atari ST vs Amiga)

Produktinterne MotivationVisuelle, technische Finesse, Tricks
Challenge „Wie geht das?“, „Könnte ich das auch?“
Echtzeitberechnung
Visuals, StorytellingSpielmechanik (Challenges)
Interaktion
Echt- und NIchtechtzeit
Genutze TechnikenVisuell, AuditivInteraktion, Taktil
Visuelle EffekteMassiv
KollisionenMeist keine ausser vielleicht PhysikdemoKollisionen extrem wichtig für die Spielmechanik
Darstellung wie gemacht Flackereffekte, AufbauMeistens kein Metalayer eher verborgen, seltene Ausnamen
ZufallMeist nicht vorhandenÖfters genutzt
InteraktionMeist nicht vorhandenHochinteraktiv, Inhalt abhängig vom Spieler
OutputsDemos, Megademos, DiskmagsGames
ArchivierungOnline (pouet.net, Demozoo.org etc)
Videos (Linearisierung)
Zines
keine
EventsParties am Wochenende meist
International
Arbeit, Treffen
wenige für Entwickler
heute GDC

// Muss stetig aktualisiert werden
// Abgleich mit Interviews / Interviews nachfragen

Exhibition: Vergleich Dev-Perspektive [Wird upgedatet]

Für eine Ausstellung wäre es gut, die verschiedenen Aspekte vermutlich tabellarisch zu erfassen. Also wie haben sich die Dinge entwickelt.

Coding

Konstrukt8Bit (Assembler) 650216Bit(Assembler) 68000C#
Möglichkeiten8 Datenregister zum Rechnen
D0-D8
8 Datenregister (B,W oder L)Diverse Datentypen:
Bool
Int
Float
Double
String
Objekte, Klassen
Add/Subadd #4,d1
Problem: über 255
sub #4,d1
Problem: unter 0
add.b #1,d0
add.w #1,d0
add.l #1,d0
d++
d=d+1
d+=1
Überfläufe werden kontrolliert.
Multiplikationnur mit Bitshifting
> < *2 / 2
nur mit Bitshifting
> < *2 / 2
Floating etc
Vergleich cmp #5,d0
bne not5

; code
not5:

Problem:
– Control bits
– 2er oder 10er System
– Max. Sprungweite!
– Kein copy-paste ohne Anpassung >Fehleranfällig
cmp.l #5,d0
bne not5

; code
not5:





Problem:
– Kein copy-paste ohne Anpassung >Fehleranfällig
if (d==5) {

}
For-Next move #0,d0
f010:
inc d0
cmp #5,d0
bne f010

move.l #5,d0
f010:

dbra d0,f010

for (int i=0;i<5;i++) {
}

Objekt-VerwaltungSimulation von Objekten durch Listen
; objekt id,x,y
dc.b 1,5,10
dc.b 4,30,90
Probleme: x>255
Simulation von Objekten durch Listen
; objekt id,x,y
dc.w 1,5,10
dc.w 4,30,90
Class GObject {
int id = 1;
int x = 100;
int y = 30;
}
GObject[] arrObs = new GObject[3];

Verwaltung der Objekte auch oft über die Objekte im Szenentree

// Weitere Beispiele von Komplexität und Auswirkungen in der Praxis