was haltet ihr davon? Glaubt ihr das er das hinbekommt? LINK: http://mikrocontroller.bplaced.net/wordpress/ wäre schon cool, denke aber das wird ein haufen arbeit sein (wobei der STL viewer ja scheinbar schon fast fertig ist)
:
Verschoben durch User
Josef schrieb: > was haltet ihr davon? Glaubt ihr das er das hinbekommt? > LINK: http://mikrocontroller.bplaced.net/wordpress/ > > wäre schon cool, denke aber das wird ein haufen arbeit sein > (wobei der STL viewer ja scheinbar schon fast fertig ist) Natürlich geht das, Elite kam damals für den Amiga 500. Der hatte einen 68000 mit rund 7MHz, der F4 hat einen Cortex-M4 mit >100MHz. Der 68000er ist eine 16-Bit-CPU der F4 ein 32bitter. Der F4 dürfte Faktor 50 mehr Leistung haben, oder mehr. 80 frames sind ein absolutes Armutszeugnis für die Implementierung.
soso... schrieb: > Der 68000er > ist eine 16-Bit-CPU der F4 ein 32bitter. > Der F4 dürfte Faktor 50 mehr Leistung haben, oder mehr. Der 68k ist ein 32bitter. Faktor 50 kann echt eng sein bei der Emulation eines kompletten Systems.
Safari schrieb: > Der 68k ist ein 32bitter. Nö. Er konnte zwar intern mit 32Bit-Zahlen rechnen, hatte aber nur einen 16-Bit Datenbus. Er war also ein 16bitter.
Xperte schrieb: > Er konnte zwar intern mit 32Bit-Zahlen rechnen, hatte aber nur einen > 16-Bit Datenbus. Er war also ein 16bitter. Was für eine Quatsch-Definition. Es ist eine 32bit CPU, die nach aussen nur einen 16bit Datenbus hat. Nur weil jeder Zugriff auf zwei aufgeteilt werden muss, wird da keine 16bit CPU draus.
Achja, meine 486GX Systeme sind 16bitter, haben ja auch nur einen 16bit Datenbus.
soso... schrieb: > Der hatte einen > 68000 mit rund 7MHz aber auch einen eigenen Grafik-Coprozessor ich denke die CPU funktionen sind bei der Umsetzung nicht das Problem
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.
wollte es gerade chriebe. Auf dem Schneider CPC gab es das Spiel ebenfalls..oder auch MArble Madness .-)
Josef schrieb: > soso... schrieb: >> Der hatte einen >> 68000 mit rund 7MHz > > aber auch einen eigenen Grafik-Coprozessor > ich denke die CPU funktionen sind bei der Umsetzung nicht das Problem Was der genau tut, weiß ich natürlich nicht. Aber 3D-Beschleuniger (solche die Vektorgrafiken berechnen) hatter der Amiga meines Wissens nach nicht. Mal im Ernst, auf dem STM32F4 wurden schon viel anspruchsvollere Spiele zum Laufen gebracht: https://www.youtube.com/watch?v=bRNcfsDIc2A Und ja, Doom ist erheblich anspruchsvoller als Elite. Erheblich. ES wäre sogar Quake möglich. Das müsste nämlich laufen, das benötigt einen Pentium 75. Da könnte ein STM32F4 durchaus noch mithalten. Der Quellcode ist offen: https://github.com/id-Software/Quake Quake benötigt keinen 3D-Beschleuniger.
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.
:
Bearbeitet durch User
Safari schrieb: > Xperte schrieb: >> Er konnte zwar intern mit 32Bit-Zahlen rechnen, hatte aber nur einen >> 16-Bit Datenbus. Er war also ein 16bitter. > > Was für eine Quatsch-Definition. > > Es ist eine 32bit CPU, die nach aussen nur einen 16bit Datenbus hat. Nur > weil jeder Zugriff auf zwei aufgeteilt werden muss, wird da keine 16bit > CPU draus. Unsinn. Der 68000er hat ein 16-Bit ALU, daher ist es ein 16-Bitter. Hat auch Motorola nie anders behauptet. Allenfalls kann man ihn als 16/32-Bit Hybriden bezeichnen. Er ist aber definitiv kein 32-Bitter.
Markus M. schrieb: > Es gibt im Amiga mehrere "Custom Chips" die dafür emuliert werden > müssen. Mag ja sein, im Fall von Elite ist das jedoch völlig irrelevant. 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. Siehe auch: https://de.wikipedia.org/wiki/Elite_(Computerspiel) 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 ;-) Im Übrigen: NATÜRLICH ist die Rechenleistung eines STM32 weit jenseits der einem Amiga. Chips hin, Chips her. Er ist fast 30 Jahre jünger, seit dieser Zeit hat sich die Performance um mindestens 3 Größenordnungen verbessert. Da ist es doch keine Kunst, die Rechneleistung zu toppen. Der Amiga 500 war zu seiner Zeit wirklich revolutionnär. Aber gegen zeitgenössischer Hardware sieht das kein Land. Ist doch völlig normal.
Safari schrieb: > Es ist eine 32bit CPU Nö. Erst der 68020 war eine 32bit CPU. Und hatte dann auch einen 32bit Datenbus.
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 :)
:
Bearbeitet durch User
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.
Markus M. schrieb: > soso... schrieb: >> Mag ja sein, im Fall von Elite ist das jedoch völlig irrelevant. > > Achso, das weisst Du genau woher? Weil Elite vor lange vor dem Amiga 500 erschienenn ist (Elite : 1984 <> Amiga 500 : 1987). Weil man 1984 nicht nichtexistente Hardware von 1987 emuliert hat. Weil Elite auf zig Plattormen erschienen ist. Daher. Es gibt noch mehr Argumente ;-)
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.
:
Bearbeitet durch User
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.
Markus M. schrieb: > 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. Alles kein Hexenwerk, die Beschleunigerhardware ist im wesentlichen nichts weiter als ein paar DMA-counter und ein bisser bitmap XOR/OR. > 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. Naja CISC macht die Sache eher einfach als schwierig, weil CISC bedeutet das ein Befehl über mehrere Takte gestreckt wird. Selbst für ein NOP braucht der 68k 4 Takte, für ein simples OR können es je nach Operanden auch 20 Takte sein. Und das nur wenn die CPU mal an den Speicher darf, weil der der CPU öfters für die Extrachips entrissen wurde: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02D4.html Und viele Commodore "Spezialchips" wie der CIA, lassen sich reltiv leicht durch die ARM -Peripherals Timer, UART etc. ersetzen. Das Geniale am Amiga war eher die UMA-Architektur, also der vereinfachte Zugriff auf den zentralen Speicher ohne über extra AddOns wie Grafikkarten gehen zu müssen. Das erspart auch der CPU unnötoges Datenschaufeln (Blockcopies). Deshalb könnte ein 7.* MHz Amiga mit 512K einen 386 mit 40 MHz und extra Grafikkarte ausstechen, Bei Auflösungen von 320×256 mit 32 Farben ... https://youtu.be/rsuWgLEQBxM?t=211 Da mal eine Entwicklung der Elite-Grafik über die Jahre: https://www.youtube.com/watch?v=iKUaxSBe6oc
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.
:
Bearbeitet durch User
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.