Asteroids auf AVR Scope-Clock

[Johann L. (gjlayde)]

Hi, ich wollt hier mal meinen Asteroids-Clone auf AVR vorstellen, 
programmiert in GNU-C auf einem ATmega168.

Ganz fertig ist's noch nicht, aber man kann schon gut erkennen, wie's 
werden soll. Mit FPGA-Implementierungen kann ein AVR natürlich nicht 
mithalten, aber nach anfänglicher Skepsis, ob das überhaupt sinvoll 
umsetzbar ist, war ich dann doch überrascht, wie viel mit einem AVR geht 
:-)

http://www.youtube.com/watch?v=TDiPibnHgW4

Grüß

[Martin (Gast)]

... Mit FPGA-Implementierungen kann ein AVR natürlich nicht mithalten 
...

Gefällt mir dein Projekt. Gibt es eine Seite auf der ich mehr erfahren 
kann?

Das Orginal lief auf einem 6502 (?) - da sollte ein ATMega doch gut 
mithalten können.

[Volker R. (pcl86)]

Hallo,

da sag ich doch auch: wo gibt´s mehr?

Zumal ich hier noch eine DG7-16 ´rumliegen habe...
Gruß
Volker

[Lehrmann M. (ubimbo)]

Servus,

saucool - würdest du uns den Source-Code zur Verfügung stellen?

Dankeschön

[Lukas K. (carrotindustries)]

Martin schrieb:
> Das Orginal lief auf einem 6502 (?) - da sollte ein ATMega doch gut
> mithalten können.
Dem 6502 stand auch noch ein Vektorprozessor in Form eines TTL-Grabes 
zur Seite.

[Johann L. (gjlayde)]

Martin schrieb:
> Gefällt mir dein Projekt. Gibt es eine Seite auf der ich mehr erfahren
> kann?

Ab und an mach ich nen Snapshot auf (Link ganz unten)
   http://www.gjlay.de/pub/morpheus
Mit der Version geht allerdings kein Build. Dazu einfach ein touch foo.c 
oder foo.c ausm Makefile rauswerfen.

Falls sich wer dafür interessiert und Fragen sind, kann ich versuchen 
die Quellen besser zu dokumentieren wo Verständnisprobleme sind. Dadurch 
wird vielleicht auch bei mir der Knoten im Kopf kleiner ;-)

[Johann L. (gjlayde)]

... oder direkt den Snapshot

[Grrrr (Gast)]

Also ich muss schon sagen. Hut ab. Toll.

[Johann L. (gjlayde)]

Danke.

Momentan ballert das Ufo (U) ziellos in die Gegend und ich frag mich 
gerade, wie man es (in einem höheren Level) anstellen kann, daß es in 
etwa in die Richtung des Raumschiffs (A) schiesst.

Die Richtung, in der der Schuss s geht, soll also

$$\vec{a}\approx \vec{A} -\vec{U}$$

sein, während die Geschwindigkeit v vorgegeben ist:

$$|\vec{s}\,| \approx v \quad\text{und}\quad \vec{s}\,\|\,\vec{a}$$

Die Lösung

$$\vec{s}\, = \frac{v}{|\vec{a}|} \vec{a}$$

scheidet leider aus, weil man dazu erstens dividieren muss und zweitens 
ne Quadratwurzel zu berechnen hat.

Jemand ne Idee wie es ohne Division und ohne Wurzel geht?

[Johann L. (gjlayde)]

So, hab auch das gelöst, ist eigentlich ganz naheliegend. Zunächst wählt 
man einen zufälligen Einheitsvektor s und verwendt

$$\vec a\cdot \vec s = |\vec a| \cos(\sphericalangle(\vec a, \vec s))$$

Ist nun a*s > 0 und bildet s mit a einen Winkel kleiner als phi_0 dann 
ist das gleichbedeutend mit:

$$(\vec a\cdot \vec s)^2 \geqslant |\vec a|^2 \cos^2(\varphi_0)$$

Ist diese Ungleichung erfüllt, dann zeigt s ungefähr in die Richtung von 
a mit einer maximalen Winkelabweichung von phi_0. Um das zu testen 
braucht man weder Division noch Wurzel. Die cos-Konstante ist nur vom 
Level abhängig und kann fest vorberechnet werden.

Ist die Ungleichung nicht erfüllt, wird im nächsten Frame des Spiels 
einfach ein neuer Kandidat für s bestimmt und getestet, solange bis 
einer gefunden ist.

[Lukas K. (carrotindustries)]

Cooles Projekt :) Kannst du auch die Helligkeit der Röhre steuern? Beim 
originalen Asteroids wird afaik der "Schuss" absichtlich überstrahlt 
gezeichnet.

[Johann L. (gjlayde)]

Luk4s K. schrieb:
> Kannst du auch die Helligkeit der Röhre steuern?

Nö, nur per Poti einstellen.

Es gäbe die Möglichkeit, nen Schuss mehrfach zu zeichnen, wodurch er 
dann heller erscheint.

Momentan wird die Helligkeit softwaremässig durch die Anzahl der 
Pixel/Frame bestimmt, ist momentan glaub auf 1400 festgelegt. Hat ein 
Frame weniger Punkte, dann wird die Zeit vergammelt. Dadurch wird 
vermieden, daß Franmes, die weniger Punkte haben, heller erscheinen als 
Frames mit vielen Punkten.

Beim Start von Asteroids geht die Helligkeit anfangs etwas zurück, so 
daß hier wohl mehr als 1400 Pixel gepinselt werden; wieviel es ungefähr 
sind, weiß ich aber net.

Bei Snake wird die Spielfeld-Umrandung gezeichnet, indem der e-Strahl im 
Abstand von 4 Pixel gesetzt wird ohne ihn dazwischen auszutasten. 
Dadurch werden die wesentlichen Spielelemente Snake+Futter+Score 
hervorgehoben. Hauptsächlich hat das aber den Zweck, nicht so viele 
Pixel zeichnen zu müssen, denn wenn ein Frame länger als ca. 1/35 
Sekunde braucht, fängt die Röhre (bzw. der GJ-Schirm) an zu flackern. 
Mit den 1400 Pixel/Frame und den 48000 Pixel/Sekunde ergeben sich ca. 35 
angezeigte Frames/Sekunde (berechnet werden teilweise mehr oder auch 
weniger, denn die Frame-Anzeige läuft asynchron zur Frame-Berechnung)

Die Möglichkeiten, nen "frei fliegenden" e-Strahl zu  nutzen, um 
dunklere oder rasterlose Linien zu zeichnen, sind aber recht 
eingeschränkt, denn dabei bewegt sich der Strahl weder in einer geraden 
Linie noch mit konstanter Geschwindigkeit von A nach B. In einem 
Testbild kann das aber recht aufschlussreich sein.

[Johann L. (gjlayde)]

Ne lustige Version von Snake ist übrigens hier zu sehen. Allerdings ist 
das Display recht teuer und auch ziemlich sperrig...

http://www.youtube.com/watch?v=VrzY8mBeXg4