Elite auf dem STM32

Elite gab es schon auf 8Bittern (C64 & andere), mit 1 Mhz. Ich würde mal 
salopp behaupten, sogar auf einem ATmega könnte man Elite mit einem GLCD 
spielen (nicht emuliert), wobei hier wohl eher der RAM als der CPU-Takt 
der Flashenhals wäre.

Josef schrieb:
> ich denke die CPU funktionen sind bei der Umsetzung nicht das Problem

Nein, denke ich auch nicht. Wenn man es nicht emuliert, müsste man den 
Ursprungscode haben (evtl. in Assembler) und ihn für die Zielplatform 
erneut umsetzen (in C oder auch wieder Assembler). Kniffe im Code, die 
reichlich bei den 8Bittern angewendet wurden, sind evtl. nicht 1:1 
umsetzbar bzw. man müsste z.B. für den ATmega eigene Kniffe anwenden, 
aber machbar würde ich das Ganze (z.B. auf einem ATmega128 o.ä. mit 
genügend RAM) halten.

Für einen 32Bitter (STM32) halte ich das für keine Herausforderung.

Es gibt im Amiga mehrere "Custom Chips" die dafür emuliert werden 
müssen.

Zum einen der Copper, welcher einfach gesagt an bestimmten Rasterzeilen 
während des Bildschirmaufbaus bestimmte Aktionen ausführen kann (nämlich 
die anderen Custom Chips steuern), zum anderen der Blitter, welcher 
schnell Flächen füllen und Linien zeichnen kann.

Wenn das "Gast-"Programm trickreich programmiert ist, muss diese 
Emulation zyklengenau und natürlich zeitgenau erfolgen, damit es richtig 
funktioniert.

Nicht zu vergessen die Emulation der bitplane basierten Grafik.

Die Soundausgabe über D/A-Wandler ist da eher Nebensache.

Außerdem ist der 68k ein CISC, der ARM ein RISC. Ich denke es ist nicht 
trivial das effizient hinzubekommen, an ASM führt wohl kein Weg vorbei.

Xperte schrieb:
> Safari schrieb:
>> Es ist eine 32bit CPU
>
> Nö. Erst der 68020 war eine 32bit  CPU. Und hatte dann auch einen 32bit
> Datenbus.

68k = Registerbreite 32-Bit und - bis auf ein paar Ausnahmen 1) - auch 
alle arithmetischen und logischen Operationen auf 32-Bit Operanden. Wie 
die Daten in die CPU rein oder raus kommen ist egal, ebenso ob bspw. 
eine Addition in einem Schritt oder mehreren durchgeführt wird 
(abgesehen davon, dass es u.U. langsamer ist).

1) muls und mulu 16x16=32, ab 020 32x32=32 und 32x32=64
divs und divu 32/16=16q+16r (16-Bit Quotient und 16-Bit Rest), ab 020 
auch 32/32=32q, 32/32=32q+32r, 64/32=32q+32r

Mr. Big schrieb:
> Unsinn. Der 68000er hat ein 16-Bit ALU, daher ist es ein 16-Bitter.

Dann wäre der Z80 ein 4 bit-Prozessor. Ist er aber nicht.
Folglich ist deine Definition nicht so ganz sinnig.

Entspannt euch mal... Der 68000'er war ein 16/32 Bit'ter. Erst später, 
mit dem 68020,68030,68040, wurde der Amiga 500 zum echten 32 Bit'ter.

Ab 68020 hatte diese Prozessoren Komponenten was viele andere CPU's erst 
viel viel später hatten... Ich denke da z.b. an den barell shifter

Also, ich würde den STM32F4 nicht unbedingt im dreistelligen 
Faktorbereich schneller als den 68040 im Amiga 4000 sehen..eher im 
unteren zwei stelligem Faktor.

Also redet nicht den 68000'er schlecht, auf dem habe ich noch gelernt.

soso... schrieb:
> Mag ja sein, im Fall von Elite ist das jedoch völlig irrelevant.

Achso, das weisst Du genau woher?

> Das Spiel ist 34 Jahre alt. Es ist 1984 zuerst erschienen. Elite ist auf
> vielen Plattformen erschienen, dem C64, dem PC, dem Amiga, und vielen
> anderen. Ich dachte, das wäre allgemein bekannt.

Ja, ich hab's damals sogar auf dem C64 gespielt. Verdammter 
Docking-Autopilot :)

> Da es eine C-64-Emulation auf dem STM32 gibt:
> https://hackaday.com/2014/10/23/a-complete-c64-system-emulated-on-an-stm32/
>
> Würde ich zunächst versuchen, die C64-Version auf dem (schon
> existierenden) Emulator zu starten ;-)

Eine C64 Emulation dürfte - bis auf den SID - wesentlich einfacher sein. 
(Und Elite hatte wimre nicht wirklich viel Sound).

Aber es ging ja um den Amiga, und die Emulation eines solchen, inklusive 
der CC, dürfte nunmal relativ aufwändig sein. Die Programmierung der 
Custom-Chips gehörte damals - auch bei einfachen Spielen - zu den 
Grundlagen. Jedes Programm (selbst die grafische "Workbench") hat diese 
verwendet - meistens (im Gegensatz zu Spielen) allerdings indirekt über 
die Bibliotheken.

Erzähl mir nix vom Amiga / 68k, habe auf den Dingern 10 Jahre lang 
programmiert :)

Markus M. schrieb:
> Aber es ging ja um den Amiga, und die Emulation eines solchen, inklusive
> der CC, dürfte nunmal relativ aufwändig sein.

Es ging um Elite auf dem STM32. Dazu gehört nicht unbedingt die 
vollständige Emulation eines kompletten Amiga, nur weil es das Spiel 
auch für diese Plattform gab...

Markus M. schrieb:
> Aber es ging ja um den Amiga, und die Emulation eines solchen,

Nein, wenn ich die Titelzeile dieses Threads und den Inhalt des ersten 
Postings richtig interpretiere ging es nicht um Amiga oder irgendeine 
andere Plattform sondern um Elite.

Bernd K. schrieb:
> sondern um Elite

... auch nicht wirklich. Er fragt nur "ist es möglich?", mehr nicht 
(insbesondere hat er nicht gesagt, dass er das angehen will - zumindest 
habe ich das nirgendwo gefunden).

Elite ist deutlich mehr als der eine Gouraud-schattierte, rotierende 
12-Flächner den's da zu sehen gibt.

Oolite (ein freier, OpenGL-basierter Elite-Klon, der übrigens ganz 
passabel funktioniert) hat z.B. mehr als eine halbe Million Code-Zeilen. 
Auch wenn ein wesentlicher Anteil davon sicherlich auf die (gegenüber 
dem Original deutlich verbesserte) Grafik zurückzuführen sein dürfte, 
ist das nicht mal eben an einem Nachmittag gemacht.

Josef schrieb:
> was haltet ihr davon? Glaubt ihr das er das hinbekommt?
> LINK: http://mikrocontroller.bplaced.net/wordpress/

Ja klar ist das machbar.
Sieh Dir mal die Demos an, welche auf dem Acorn RiscPC liefen im Jahr 
1997, z.B. dieses hier:
https://www.youtube.com/watch?v=NR2Xw38Sp-c
Ich glaube das Demo lief gut auf einer ARM610 CPU, die mit 30MHz 
getaktet wurde und der RiscPC hatte nicht mal einen Grafikbeschleuniger.
Also sollte Elite auf einem STM32F7 auch machbar sein.

Ihr habt recht - es ging tatsächlich NUR um Elite - nicht um Elite auf 
dem Amiga xxx, hatte ich irgendwie falsch gelesen.

Somit stimmt es natürlich, das sollte man in der Tat gut umsetzen 
können. Man könnte wahrscheinlich sogar den z.B. 6502 Code nach ARM 
umsetzen (lassen), also nicht emulieren, und muss dann nur noch die 
Stellen anpassen, wo die Grafik ausgegeben wird.

Soweit ich mich erinnere war Elite auf dem C64 ja nur s/w Grafik.

Markus M. schrieb:
> Soweit ich mich erinnere war Elite auf dem C64 ja nur s/w Grafik.

Die Polygone waren nicht gefüllt, das hat das Zeichnen schonmal sehr 
beschleunigt, das einzige das gefüllt war war das Zentralgestirn eines 
jeden Systems und das war meist immer weit weg und klein (es sei denn 
man hat ne Fuel-Scooping Tour gemacht, dann wars groß und ruckelig). Und 
noch wichtiger: Die Schiffe hatten alle eine konvexe Form so daß jedes 
Polygon immer entweder komplett sichtbar war oder gar nicht, so musste 
man immer nur das Vorzeichen der Z-Komponente des Normalenvektors 
betrachten (bzw testen ob es linksrum oder rechtsrum war) um zu 
entscheiden ob ein Polygon gezeichnet werden muss oder nicht -> 
Hidden-Line Problematik quasi zum Nulltarif umschifft.

6a66 schrieb:
> Markus M. schrieb:
>> C64 ja nur s/w Grafik.
>
> Neee, die war farbig :)
>
> rgds

Ja, die Schrift, Instrumente und HUD waren farbig. Die ganze 3d-Grafik 
war weiße Linien auf schwarzem Grund.

Amiga emuliert auf ARM gibt's doch längst: 
https://github.com/Chips-fr/uae4arm-rpi

Bernd K. schrieb:
> Und
> noch wichtiger: Die Schiffe hatten alle eine konvexe Form so daß jedes
> Polygon immer entweder komplett sichtbar war oder gar nicht, so musste
> man immer nur das Vorzeichen der Z-Komponente des Normalenvektors
> betrachten (bzw testen ob es linksrum oder rechtsrum war) um zu
> entscheiden ob ein Polygon gezeichnet werden muss oder nicht

Klingt interessant, leider hab ich das mit dem Normalenvektor auf Anhieb 
nicht ganz verstanden. Kann man das irgendwo nachlesen?

Thomas F. schrieb:
> Klingt interessant, leider hab ich das mit dem Normalenvektor auf Anhieb
> nicht ganz verstanden. Kann man das irgendwo nachlesen?

Was genau hast du nicht verstanden? Du weißt, was ein Normalenvektor 
ist?

Ein Normalenvektor ist ein Vektor, der orhtogonal auf einer Graden/Bogen 
bzw. Fläche oder Körper steht.

Ein Polygon, dass von einem anderen Polygon verdeckt wird, muss nicht 
gezeichnet werden. Und wenn man die Normalenvektoren bestimmt kann man 
bestimmen wer wen potentiell verdeckt.
Hier ist was interessantes dazu (habs grad nur überflogen)

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiH0KeOvM3bAhWrHpoKHVSZDTkQFggrMAE&url=https%3A%2F%2Fwww.inf.tu-dresden.de%2Fcontent%2Finstitutes%2Fsmt%2Fcg%2Fteaching%2Flectures%2FCG2WS0203%2Fsecure%2Fsichtbar_script.pdf&usg=AOvVaw1CGyl7IxPr8mz1XHOE6XSm

M. K. schrieb:
> Thomas F. schrieb:
>> Klingt interessant, leider hab ich das mit dem Normalenvektor auf Anhieb
>> nicht ganz verstanden. Kann man das irgendwo nachlesen?
>
> Du weißt, was ein Normalenvektor ist?
Das ist klar.

> Ein Polygon, dass von einem anderen Polygon verdeckt wird, muss nicht
> gezeichnet werden. Und wenn man die Normalenvektoren bestimmt kann man
> bestimmen wer wen potentiell verdeckt.

Das war meine Frage: Wie läuft diese Prüfung - verdeckt oder nicht - ab?
Kennt jemand spontan einen Pseudocode-Algorithmus?

Gerade gefunden:
https://de.wikipedia.org/wiki/Culling#Backface_Culling

Deinen Link werde ich jetzt erst mal durchlesen...

Thomas F. schrieb:
> Das war meine Frage: Wie läuft diese Prüfung - verdeckt oder nicht - ab?
> Kennt jemand spontan einen Pseudocode-Algorithmus?

Eigentlich simpel. Wenn der Normalenvektor einer Fläche eine 
Z-Komponente hat, die auf die Kamera zeigt (also nicht davon weg), 
siehst Du die Vorderseite, ansonsten nur die Rückseite.
Wenn Du nur konvexe "Volumen-" Objekte hast, wird die Rückseite immer 
von einer anderen Fläche verdeckt, ist also unsichtbar.

Bei konkaven Objekten kann eine "hintere" Fläche ganz oder teilweise von 
einer "vorderen" verdeckt werden. Dann muss man die "hintere" Fläche mit 
der vorderen "verschneiden", um den evt. sichtbaren Teil zu ermitteln. 
Und das ist ein erheblicher Zusatzaufwand.

Markus F. schrieb:
> Eigentlich simpel. Wenn der Normalenvektor einer Fläche eine
> Z-Komponente hat, die auf die Kamera zeigt (also nicht davon weg),
> siehst Du die Vorderseite, ansonsten nur die Rückseite.

Die Normalenvektoren der einzelnen Flächenelemente des Volumenkörpers 
müssen so definiert sein dass diese 'nach außen' zeigen, nicht nach 
innen, oder?

> Wenn Du nur konvexe "Volumen-" Objekte hast, wird die Rückseite immer
> von einer anderen Fläche verdeckt, ist also unsichtbar.

Soweit klar.

Thomas F. schrieb:
> Die Normalenvektoren der einzelnen Flächenelemente des Volumenkörpers
> müssen so definiert sein dass diese 'nach außen' zeigen, nicht nach
> innen, oder?

Ja. Die Eckpunkte der Deckflächen werden dazu entweder im oder gegen den 
Uhrzeigersinn angelegt/sortiert. "Rechtsrum" (oder entsprechend 
"linksrum") bedeutet dann per Konvention "aussen" oder "innen".

Wenn man das sicherstellt, braucht man ab da nicht mehr mitzudenken 
(bzw. unterschiedliche Fälle zu berücksichtigen), die Berechnung der 
Normalenvektoren stimmt "automatisch" immer.

Danke, jetzt habe ich einiges zum Nachdenken.
Da dauert es wohl noch ein wenig bis ich das auf einem Atmega umgesetzt 
haben...