mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Berechnete Grafik Effekte in C?


Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Ich habe ein Grafik-Display zum Rumspielen ohne konkrete Anwendung.
Genauer ein DOGM128 mit 128x64 Pixeln.
Da man das Teil nicht auslesen kann verwende ich einen Puffer von 1 KB.
Momentan spielt das Gerät eine Animation mit 4 Bildern ab.

Das Display sitzt auf einem Board mit einem 90CAN32 der auf 16 MHz 
läuft.

Jetzt würde ich gerne sowas nettes wie einen rotierenden Würfel machen.
So Effekte eben wie sie mit dem C64 schon vor 20 Jahren gemacht wurden.
Ein rotierendes 2D-Object wäre ja auch schon nett.

Nur, wie geht sowas überhaupt?
Und vor allem, wie geht sowas effizient und in C?

Wenn ich im Netz nach Grafik-Effekten suche bekomme ich haufenweise 
Photoshop Seiten...

Autor: Daniel P. (ppowers)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist alles nur Mathematik ;-)

Hier gibt es Quelltext dazu, ist zwar für einen PIC aber der Code ist in 
C:
http://www.base32.de/3dengine.html

Gruß
daniel

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein uC mit 16MHz und RISC-Architektur ist mehr als 20mal schneller als
ein C64, d.h. einfache rotierende Objekte sollten ohne Probleme möglich
sein.

Dazu: Punkte als 3D-Vektoren (fixpointed integers) per 3D-Matrizen 
drehen
etc., dazu Linien- und Clipping-Algorithmen und eine Speicheranbindung.
Das ganze ist in einem kleinen kompakten Programm möglich.


Gruss

Jörg

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese 3D Routinen sind ja mittlerweile schon fast Standard, aber wie 
macht man gefüllte Objekte wie z.B. einen sich drehenden Trichter oder 
sowas, der nicht aus einem Wireframe besteht, sondern aus einem 
Schachbrettmuster?
So in der Art wie hier ab 1:10
Youtube-Video "Pokemon Mini - SHizZLE Demo"
Auch interessant: Ab 1:20
Eigentlich sind alle Effekt interessant...

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt K.,

gefüllte Dreiecke sind eigentlich auch ganz einfach: Ein modifizierter
Linienalgorithmus erzeugt aus den 3 Eckpunkten für jede Pixelzeile
Anfangs- und Endpunkte, ein weiterer Linienalgorithmus erzeugt dann
für jedes Punktepaar eine Linie. Eine kleine Schwierigkeit ist nur
die, das die Linien zu den drei Eckpunkte nur bestimmte Punkte als
Anfangs- und Endpunkte erzeugen dürfen, und das in Abhängigkeit des
Umlaufsinns und der Lage der Eckpunkte. Einfach mal mehrere verschiedene
Dreiecke durchprobieren sollte den Sachverhalt verdeutlichen.

Gruss

Jörg

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Quellcode ist ja ganz nett, mir ist auch klar, dass das nur 
Mathematik ist - nur eben nicht, was da überhaupt passiert.

Aber ich hatte mehr auf einen Link auf ein Tutorial gehofft in dem 
erklärt wird, was man da überhaupt machen muss.
Nach sowas wie Grafik und Effekten oder auch Demo zu suchen bringt einen 
vielleicht zu Photoshop und OpenGL...

Sicherlich ist interessant zu wissen, was man machen muss, damit das 
mathematisch 100 Prozent korrekt ist.
Aber eben auch was man alles tun kann, um sowas zu beschleunigen.
Lookup-Tables für Sinus-Werte sind sicher nur der Anfang.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie findet man raus, welcher Bereich sichtbar bzw. verdeckt ist ?
Man könnte eine Liste alle Objekte machen, diese nach der Tiefe 
sortieren und dann von hinten nach vorne Zeichnen usw. Aber es geht mit 
Sicherheit effizienter.

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:
da ich die Demo z.T. mit programmiert habe, kann ich dir bissl was dazu 
erzählen.
Die ganzen Effekte sind extrem vorberechnet. Viel Speicher wurde für 
Lookup-Tabellen verwendet. Das 3D logo am Anfang und der 3D Flug am Ende 
sind nur vorberechnete Sequenzen.

Das Wurmloch bei 1:10 stammt von mir. Das Wurmloch selbst ist am PC 
vorgerendert, aber die Textur habe ich am PC noch nicht rauf gelegt. Die 
Textur wird in Echtzeit auf das Wurmloch gelegt und dann einfach 
versetzt dargestellt. Eine Bewegung der Kamera ist so natürlich nicht 
möglich.

Ab 1:20 ist eine voxel landschaft, stammt nicht von mir, kann ich nicht 
viel zu sagen ausser das die Auflösung halt sehr gering ist und die 
kamera nicht gedreht werden kann. Dadurch wurde schon viel rechenzeit 
gegenüber eines konventionellen Voxelrenderers eingespart.


Was ich mir auf einem µC ganz gut vorstellen könnte sind 
Voxellandschaften und Raytracer (wie in DOOM).
Für aufwändigere 3D Effekte wird man nicht um Polygone (Dreiecke) rum 
kommen. Und gefüllte Dreiecke, womöglich noch mit Texturen, zu rendern 
ist nicht ganz ohne. Das würde ich erst einen ARM7 zutrauen (siehe 
Gameboy Advance demos).

Für die Sache mit der Tiefe gibt es verschiedene Methoden. Erstmal 
rendert man die der kamera abgwandten Dreiecke nicht. Bei modernen 3D 
Systemen hat man einen Z-Buffer welcher dafür sorgt, dass vorne liegende 
Pixel nicht überzeichnet werden können.
Außerdem kann man mit BSP Trees (Binary Space Partitioning) einzelne 
Objekte der Reihe nach rendern. Ich habe vor Ewigkeiten mal einen 
Renderer für Quake3 maps in VB geschrieben... steck da aber nicht mehr 
so drin.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marius S. wrote:
> da ich die Demo z.T. mit programmiert habe, kann ich dir bissl was dazu
> erzählen.

Na dann weiß ich ja jetzt wen ich bei solchen Sachen fragen kann...

> Was ich mir auf einem µC ganz gut vorstellen könnte sind
> Voxellandschaften und Raytracer (wie in DOOM).

DOOM auf nem AVR würde mir für den Anfang reichen ;-)

Kennst du dazu irgendwelche Internetseiten oder sonst irgendwelche 
Lektüre die einem beim Einstieg in sowas hilft? Anscheinend gab es dazu 
nie Infos im Netz oder das meiste ist schon wieder verschwunden, 
zumindest konnte ich bisher nichts derartiges finden.

PS: Was steckt da eigentlich für ein µC drin?

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht z.B. ganz brauchbar aus:
http://de.wikipedia.org/wiki/Raycasting
http://student.kuleuven.be/~m0216922/CG/raycasting.html
http://www.permadi.com/tutorial/raycast/

Hab einfach mal nach raycasting gegoogelt.

Problematisch ist beim AVR eher die Grafik-Hardware. Also die 
Schnittstelle zum Display. Wenn der schon 50% der Zeit damit beschäftigt 
ist die Daten zum Display zu schicken dann kannst auch nicht mehr viel 
raus holen.

Im Pokemon Mini steckt eine spezielle Nintendo CPU (auf der Platine 
vergossen). Weil das keiner bekannten Architektur entspricht gibt es 
auch keinen C compiler (bisher hat's noch keiner gepackt mal einen zu 
portieren) sondern nur einen selfmade assembler.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marius S. wrote:
> Hab einfach mal nach raycasting gegoogelt.

Danke, raycasting ist also das Zauberwort. Unter Voxel war die Ausbeute 
sehr bescheiden.

> Problematisch ist beim AVR eher die Grafik-Hardware. Also die
> Schnittstelle zum Display. Wenn der schon 50% der Zeit damit beschäftigt
> ist die Daten zum Display zu schicken dann kannst auch nicht mehr viel
> raus holen.

Ich denke das sollte ich ganz gut hinbekommen. Notfalls kommt ein etwas 
größerer µC dran, der die Daten per DMA ans Display schiebt.

Wie ist das beim Pokemon Mini? Ist da der LCD Controller direkt 
integriert, so dass die Daten nur ins RAM geschrieben werden müssen?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für aufwändigere 3D Effekte wird man nicht um Polygone (Dreiecke) rum
> kommen. Und gefüllte Dreiecke, womöglich noch mit Texturen, zu rendern
> ist nicht ganz ohne. Das würde ich erst einen ARM7 zutrauen (siehe
> Gameboy Advance demos).

Ohne Texturen (bzw. in Grenzen) reicht dafür ein 68k @ 8 MHz im ST
Als Demo z.B.
Youtube-Video "Mega Tridi demo - European Demos - Overlanders (Atari ST)"
Spiele mit reiner 3D-Grafik waren z.B. der Port von Zarch aka Virus oder 
Carrier Command.

Edit: Ein ARM7 ist bei gleichem Takt ca. acht mal schneller.

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine Grafik Hardware im PM, man kann einfach in einen RAM buffer 
schreiben und die Hardware schiebt die Daten dann ins Display. Es gibt 
auch eine "Grafikkarte" die Maps und Sprites rendern kann.

Man kann das Display aber auch byteweise per software ansprechen (direkt 
den Controller ansprechen).

Ja klar, einen gefüllten Würfel bekommst wohl auch noch mit nem AVR hin. 
Aber daraus wird kein ganzes Spiel/demo/was auch immer.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollen mal nicht übertreiben.
Ich habe ein MonoChrom-Display mit 128x64 Pixeln welches per SPI 
angebunden ist und aktualisiere das Display mit momentan etwa 5 Hz.

Ich habe in der Bucht erstmal ein Buch gekauft, das nach der 
Beschreibung auf Amazon zu schliessen weit genug unten anfängt und eben 
nicht auf OpenGL oder DirectX aufsetzt.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Computer Graphics: Principles and Practice
Addison-Wesley Systems Programming Series
Sprache: Englisch
ISBN-10: 0201848406
ISBN-13: 978-0201848403
Amazon ab ca. 30,-

Es gibt nur DIESES EINE Buch zum Thema. Sonst keins.
Ist schon mindestens 20 Jahre alt, letzte Ausgabe 1995, aber beeinhaltet 
alle Grundlagen und zwar nicht oberflächlich, sondern bis in das 
ALLERletzte Detail. Das ist sowas wie die Bibel, das wird Dir jeder 
(jeder!) Insider bestätigen. Jedes andere Buch zum Thema baut letzlich 
darauf auf und von dieser Regel gibt es keine einzige Ausnahme.

Aber unbedingt beachten: NIEMALS die deutsche Übersetzung kaufen, die 
lässt die Hälfte (ungelogen) weg. Ich habe beide, kann das also 
beurteilen.

Jochen Müller

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.