Archiv der Kategorie: Assembler

Interessante Offset/Array-Schreibweise oder die heutige Notation war immer inspiriert vom Davor oder doch nicht?

Im Coden auf alten Computern geht man ja auch rückwärts in der Geschichte der Programmierung und deren Kultur. Diese Sichtweise ist natürlich meist positivistisch „im Sinne von“: Das musste ja so kommen, auch wenn die Zukunft nie geschlossen ist. Aus dem Kommentar von Assembler „;“ wurde etwa der Abschluss eines Befehls in C (?). Und dann stösst man des öftern auf Schreib- und Notationstechniken, die dann sehr nahe dran ist an heutiger Notation. Und ja die Dinge sind dann oft näher zusammen – auch technisch – als es den Eindruck macht. Und schliesslich hat sich ja alles aus diesem entwickelt. Hier auch ein Fall – Arrays, Index und Objektorientierung.

Im vorliegenden Fall werden Bälle, Paddles und Bricks eine Breakouts in 68k Assembler verwaltet im Spiel Breakout einem SizeCodeProjekt im Rahmen von CHLudens. Das Ganze ist ein grosser Word-Array (2 Bytes). Die einzelnen Objekte sind als „Zeilen“ angeordnet. Quasi ein grosses Excel mit sich wiederholenden Zeilen.

Das heisst alle 12 Bytes kommt das nächste Objekt:

Variables: RAM-Adresse

Ball: 0+
Paddle: 12+
Brick 1: 24+

Ein Objekt ist aufgebaut mit (relativ):
0: x
2: y

Hier werden nun Koordinaten reingeschrieben. a4 beinhaltet die Adresse der Variablen:


Weiterlesen

Atari ST Basics

Das Meist ist gleich oder ähnlich wie beim Amiga. 68000 Prozessor und viel Memory.

Screen-Memory

Das Screenmemory hat wie der C64 oder der Amiga so etwas wie Bitplanes. Ein (eher) Bitblock das sind 16 Pixel. Die Farbwerte werden aus 4 Ebenen zusammgesetzt, die je nacheinander kommen.

0-2 Byte: 0. Ebene Bsp: 1110000000 (*1)
3-4 Byte: 1. Ebene Bsp: 01100000000 (*2)
5-6 Byte: 2. Ebene Bsp: 0010000000 (*4)
7-8 Byte: 3. Ebene Bsp: 0000000000 (*8)

Zusammengezählt: 1 | 3 | 7 (Farbe)

Achtung so wie es scheint sind die Pixel anders rum verteilt als beim Amiga! Also Reverse!

All das verlangt ein komplexes Rechnen, um einen Pixel zu setzen. Der Amiga trennt dazu alle Farbebenen, aber auch das ist letztlich keine gute Lösung etwa gegen Systeme wie VGA (dort ist der ganze Pixel abgebildet)

Mehr zum Thema findet sich hier:
https://nguillaumin.github.io/perihelion-m68k-tutorials/_of_the_workings_of_the_graphics_memory_and_minor_skills_in_branching.html

Radikale AssemblerFreaks würden hier sagen: Der Rest lässt sich einfach darauf aubauen .-(

Das lange Leben von GOTO auch in C, Java und C#

Gibt es goto auch in C, Java oder C#? Da denkt man nein, das kann nicht sein. Das war doch das Argument gegen Assembler – nie wieder GOTOs und damit schwer les-, wart- und erweiterbaren Code. Schon gar nicht bei Sprachen mit VM wie Java oder C#.

Und dann meint CW bei einer Diskussion am Abendessen – alles Coder*: Doch das gibt es weiterhin. Und ein Blick ins Netz – altmodische Google-Suche – zeigt: Ja es gibt es als GOTO/Labels-Komplex. Es ist etwas nachdem man gar nicht sucht, wenn man denkt, es gibt es nicht.

Die Begründungen dafür (es nennt sich nun Goto/Label) sind die alten: Wie kommt man möglichst schnell aus einer tiefen Verschachtelung raus.

https://www.geeksforgeeks.org/goto-statement-in-c

Und noch unglaublicher Java:

https://www.geeksforgeeks.org/g-fact-64

Keine Gotos scheinen zu kennen Javascript, Python.

Das sind natürlich im ersten Moment schlechte Nachrichten, weil es nun diese Möglichkeit wieder gibt und im zweiten Gute: Man kann es im SizeCoding eigentlich wieder nutzen.

Eine Demo kreieren, die Suche nach dem (eigenen) Motivationsdesign und die Besonderheiten

Motivation hinter Crackintros

Das Motivationsdesign hinter der Crackerszene war divers. Von Personen, die einfach nur ein Spiel bis zu Ende spielen wollten (Trainer), über Personen die Spiel ‚befreien‘ wollten vom Kopierschutz bis hin zu Leuten, denen es vorallem um symbolisches Kapital in ihrer Community von anderen Cracker ging (siehe Artikel von Gleb). Die CrackIntros darin hatten diverse Funktionen – Messages zu den Endkunden (geteilt in direkten Messages übers Spiel, (Bewertung), Kommentare zum Spiel, zum Cracken und Adresse fürs Einschicken/Kontaktaufnahme, Mitgliederwerbung, Zeigen wie Cool man ist), Message an Kollegen (Crackprozess, Zeit des Crackens, Crackart, Gepose), Message an andere „böse“ Gruppen (Crackprozess, Zeit des Crackens, Crackart, Gepose, Erniedrigungen), meist keine politischen Messages und Message an ! die GameDesigner/Publisher (Wie einfach es war es zu cracken). Die GameDesigner haben ja auch ihre Message in den Programmen hinterlassen und so vor- bzw. zurückkommenuziert. Siehe BlogEintrag. Aber all diese Motivationen waren klar und Teil des Grafitti-Products „gekracktes Spiel“.

Metaspiel CSDB

Siehe dazu auch das Metacrackspiel csdb.dk heute auf lemon64.com, wo immer noch gecrackt, Trainer eingebaut werden, dafür gibt es nun aber Punkte und am Ende des Jahres hat jemand gewonnen. Eine Art Operationalisierung und Objektivierung des Wettbewerbs.

https://csdb.dk/release/?id=236312

Motivationsdesign hinter (eignen) Demos?

Ganz anders sieht es bei der entstehenden Demoscene aus – das Motivationsdesign ist viel diverser, weil auch weder das Produkt noch die Community noch die Endnutzer so klar definiert scheine. Sicher ist, dass das Medium Intro im Medium Demo viele ihrer ursprünglichen Funktionen verloren hat.

Weiterlesen

Metall, „Farbverläufe“ & Reflektionen in 16/32-bits-Demos&Games – eine (manuelle 3D-)Designtechnik

Wenn man sich fragt, warum benutzen so viele AtariST/Amiga-Demos so viele Reflektionen bzw. Farbverfläufe in kleinsten Abschnitten/Flächen, dann ist die erste Antwort: Damals hatte man endlich 16/32 Farben und Farbauswahl, deswegen konnte man hier protzen, handgerendertes 3D war endlich möglich. Sicherlich ist das einer der grossen Motivationsmechaniken, aber eine zweite Motivationsmechanik ist eben auch da (das bemerkt man spätestens wenn man selbst gestaltet: Es hilft zu vertuschen, dass man nur 16/32 Farben aus einer eigentlich spärlichen Palette 512 oder 4096 Farben zur Verfügung hat bei 320×200(256) Pixeln hat. Grossflächige von Hand geshadete Kugeln etc. ist das selbst bei einem ‚verchmierenden‘ CRT – einfach zu abgehackt und grosse Flächen mit „Treppenabstufungen“ (auch für Antialising benötigt man viele Farben) lassen sich damit verhindern. Hier einige kreative Beispiele. Weil Reflektionen immer auch zu „Weiss“ tendieren (direkte Reflektion) können hier auch immer die Graustufen/Gelbstufen wiederverwendet werden.

Selbstverständlich geht all dies auch Hand in Hand mit den Möglichkeiten von „Sprayen“ in den gängigen Malprogrammen oder eben im Analogen mit Sprayen (Grafitti) und Airbrush.

In Schriften und am Rand (gerade vo Schriften) immer gut nutzbar „Pseudo“-Metall. Im Innern dann wieder eine andere Farbe (als wäre es ein anderes Material) und das Gestaltungsspiel kann von neuem losgehen. Dabei braucht es hier nicht besonders viele Farben – so 2 * 4?

Schriften sind ein besonders beliebtes Anwendungsfeld. Die Gründe sind schnell klar: Die Buchstaben wiederholen sich oft und müssen dennoch abwechslungsreich sein. Unten mehrere Spiegelungen und Verläufe. Dadurch entsteht selbstverständlich ein 3D Effekt (aussen herum) und im Inneren ebenfalls eine interessante Beleuchtung bei „ZEALAND“.

Noch besser funktioniert das Ganze natürlich bei noch kleineren Schriften. Hier verschwimmen auf einem CRT die PixelFarben. Aber auch hier eine Beleuchtung von Oben und Spiegelung von unten?

Weiterlesen

Hardware-Collision C64 – praktisch ohne Nutzen

// Alles in einem Byte – alle Kollisionen – untrennbar

Das es mit der Hardware-Collision nicht sehr weit her sein muss, zeigen eindrücklich die Hardware-Collisionsroutinen des C64. Hier gibt es die Routinen: Sprite-vs-Sprite und Sprite-vs-Background. Die Sprite vs Background fragt wirklich letztlich nur den Hintergrund ab. Die (pixelgenau) Sprite-vs-Sprite-Routine liefert einfach ein geflatetes Byte mit dem aktuellsten Collisionsstand. Also etwa (von links nach rechts zu lesen): 01011001

Das erste Sprite kollidiert gerade mit dem 4. oder das 4te und das 5te oder das Fünte mit dem ersten.

Das Ganze ist also maximal ambigue und deswegen auch nicht wirklich nutzbar und so – zumindest einige Blog-Artikel – auch nicht wirklich genutzt worden dann. Dabei ist auch hier die Frage – waren das Problem die Kosten? Ein Byte pro Kollision von Spritex mit allen anderen Sprites würde ja nur 7 Bytes mehr benötigen (1 verwendet man ja schon)! Der C64 ist ja bekanntlich eine auf Kosten optimierte Computerspielmaschine.

// Insofern schwierig zu verwenden etwa im Sizecoding, wo man dann nicht durch eine zweite Methode bestimmen kann, wer da mit wem kollidiert.

move.l: Verschieben oder Kopieren?

Der Move-Befehl ‚verschiebt‘ einen Wert von A nach B – so sagt es zumindest das Naming. Eigentlich verschiebt er den Wert nicht nur, sondern er kopiert ihn. Aber selbstverständlich wird er damit auch ‚verschoben‘. Es wäre auch eine gute Frage, falls er ihn ‚verschieben‘ würde, was an dessen Stelle wäre am alten Ort. Das wäre ja ein ‚echtes‘ Verschieben.