Hallo Leute,
ich kam vor kurzem auf die Idee mal etwas 3D mit meinem AVR Mega2560 zu
machen. Das ganze läuft auf einem T6963C Display mit 240*128 Pixeln.
Der aktuelle Code liegt im Anhang und ist ALLES ANDERE ALS EINE FERTIGE
LIB!
Ich stelle den Code aus zwei Gründen schon ein: Zum einen, weil mich
generell interessiert ob jemand Bedarf an sowas hat und zum anderen ob
jemand Lust hat daran in Anlehnung an die OpenGL API weiter zu
programmieren.
Klar ist, dass das ganze so schnell wie möglich sein muss, sonst bringt
es nicht viel. Außerdem sollte das ganze sehr klein bleiben und so
einfach wie möglich sein.
Bei mir dreht sich hier eine kleine Pyramide flüssig auf dem LCD,
allerdings habe ich noch ein Problem:
Wenn ich die Vertex-Koordinaten meines Objekts negativ mache, dann
flippt die Rotationsberechnung total aus. Das ist sehr ungünstig, da ich
so keine Möglichkeit habe ein Objekt um seinen tatsächlichen Mittelpunkt
zu rotieren... Kennt sich jemand ausreichend gut mit Matrixberechnungen
und/oder Vektormathematik aus um den Fehler zu finden?
Gruß und wer weiter schreibt, bitte hier wieder einstellen, damit andere
auch wieder darauf aufbauen können :)
Timo
Nein, bisher nicht. Ich würde gerne noch weiter programmieren um mit der
Trägheit des Displays zu experimentieren. Das Problem bei Bewegungen auf
einem alten LCD ist, dass man schnelle Pixelwechel praktisch garnicht
erkennt. Ein komplett löschen des Screens ist bei dem T6963C leider
garnicht möglich, darum muss man sich einen Trick ausdenken um das
möglichst schnell erledigen zu können.
Dazu hatte ich zwei Sachen im Sinn:
1. Ubermalen der grade gezeichneten mit nicht gesetzten Pixeln, also
alles Pixel per Pixel wieder löschen. In dem Fall muss man aber immer
die ganze Scene zweimal zeichnen.
2. Einen Speicherbereich im Display komplett löschen und dann
Pixelzeilenweise in den Sichtbereich kopieren. Das merkwürdige ist, dass
das Display ein kopieren von ganzen Zeilen also 240*1 von einem Ort zum
anderen zu unterstützen scheint. Wenn das geht, könnte man mit grademal
128 Kommandos das Display komplett löschen, statt der bisher in jeder
Lib verwendeten 30720*2 Kommandos. Das habe ich aber noch nicht
getestet.
Die Lib kann bisher auch beinahe nichts, da zum einen die Berechnungen
für die Darstellung der Vektoren nur für eine Orthogonale Darstellung
geeignet ist und bisher keine perspektivische Verzerrung unterstützt.
Außerdem wird außer glVertex und glLine noch nichts unterstützt :)
Gute Idee!
Hab das mal ausprobiert, ist in der Tat noch nicht viel drin los in
deinem Programm.
Anmerkungen:
- 8 Bit signed als Datentyp für Objekte und Translation ist zu wenig.
- Benutze besser standard Datentypen (uint8_t, int8_t etc)
- Arrays legt man nicht in .h Dateien an
- Die Matrixoperationen würde ich mehr kapseln. Eventuell in Inline
Funktionen. Bzw. einstellbar ob Inline oder nicht (Max
Geschwindigkeit/Kleinste Größe)
- Stubs für glBegin und glEnd hinzufügen um mit standard OpenGL code
kompatibel zu sein
- die glcd_ Calls hast du fest eingebaut, das würde ich per Define
extrahieren in einen Konfigurationsheader
- glRotationMatrix würde ich in höherer Auflösung speichern und nur bei
der Ausgabe herunterrechnen. (Fixed Point)
- Zu viele Divisionen in glVertex. Da verliert man unheimlich an
Ungenauigkeit. Außerdem fehlen mir auch Rundungen etc.
- Dein Ursprungspunkt liegt in der Mitte des Screens (So wie bei der PC
Version?). Da müsste man auch ein paar Konfigurationsdefines hinzufügen
um einen konstanten Offset einbauen zu können. Ansonsten hing bei mir
alles oben links im Fenster.
Soweit erst mal. Hast du denn noch Lust weiterzumachen? Habe mal ein
kleines Windowsprogramm gebaut, wo man die Lib ausprobieren kann. Ist
mit MSVC kompilierbar. Video siehe Anhang.
Ein Beispielprogramm sieht dann so aus:
Der obige Code ist schon seit etlichen Jahren im Netz zu finden und
wurde eigentlich für einen M16C geschrieben. Ursprünglich stammt er von
hier:
http://www.mikrocontroller.com/de/m16c.php
Den Code kann man optimieren, wenn man anstelle der 32bit Variablen nur
16bit Festkomma verwendet und das ganze in Assembler berechnet (oder
zumindest nur die 16x16->16bit Festkomma Multiplikationen in Assembler
macht). Mit 8x8bit Berechnungen wird der Fehler zu groß, 16bit ist also
schon sinnvoll.
Sobald die Modelle komplexer werden, ist ein AVR allerdings schnell
überfordert, vor allem da für eine 16bit Operation mehrer Takte
erforderlich sind. Im Anhang mal ein Video von einem deutlich
aufwendigeren Modell auf einem 320x240LCD, berechnet von einem dsPIC der
nebenbei auch noch LCD Controller spielt.
Moin Benedikt!
Wir haben ja mal zusammen das 4" Display Projekt gemacht!
Der Code stammt von hier: http://www.mikrocontroller.com/de/m16c.php
Das steht aber auch in der .h Datei. Ich habe erstmal nur den ganzen
Codehaufen in unterschiedliche, intelligent benannte Funktionen
untergebracht. Ich habe den Code natürlich übernommen - mit den dazu
gehörigen Credits :)
Ich fand es sehr gut, dass man mit dem AVR solchen Schabernack treiben
kann, darum habe ich gehofft, dass es irgendwer mal weiter /
umprogrammiert :)
Total uneigennützig natürlich.... natürlich! ;-)
Stimmt, in der h Datei stehts. Ich hatte mir nur die .c angesehen und
der Code kam mir sehr bekannt vor.
Ich hätte den kompletten Code, optimiert in Assembler für AVR, falls
interesse besteht.
Allerdings nur mit 8bit Berechnungen, d.h. mit relativ großen
Rundungsfehlern.
Hallo!
Wusste gar nicht, dass da in der Richtung schon mal jemand was probiert
hat. Habe nur was zu tun gesucht und deswegen eine kleine Testsuite
gebaut für den Code vom TO.
Wenn da aber schon so viel fertiger Code parat liegt, lohnt es ja schon
fast gar nicht mehr da noch mal neu anzufangen.
Aber tolle Sache!
