Maximale mögliche Auflösung / Farbanzahl

[drohne235]

Bin mal gespannt, wer als erster eine tolle Vectorgrafik mit nur 2 Bildzeilen Puffer hin bekommt.

Fakt ist eines: Eine derartige Engine wäre für den Propeller absolut revolutionär und innovativ!

[Janaha]

Hm,

man könnte ja auch die anzahl der Pufferzeilen raufschrauben. Wenn man z.B. 4 statt nur 2 Zeilen puffert könnte man evtl. besser verkraften, wenn mal das Zeichnen einer Zeile etwas länger dauert. Wenn dafür die nächste Zeile dann wieder fast leer ist, holt man die verlorene zeit wieder ein bevor die Zeile wirklich gebraucht wird. Sprich hier gibts viel platz zum optimieren. Den zugriff auf den 32K Ramblock kann man mit Assembler recht gut timen, so das ein Cog immer mit der maximal besten zugriffszeit also jeden 8. Takt einmal auf's 32K Ram zugreifen kann. Der zurgiff hier macht mir daher auch keine sorgen. Und wie Drohne schon sagte, ein Cog kann intern ja eine Liste von Linien bekommen, die zu zeichnen sind. Damit reduziert man dann die nötigen 32K-Ram zugriffe enorm.

Grüße
Janaha

[laserjones]

Fakt ist eines: Eine derartige Engine wäre für den Propeller absolut revolutionär und innovativ!

Und eine echte Rechtfertigung für das 3-Propeller-Konzept. Idealerweise sollte Bellatrix komplett für die Engine genutzt werden, dann wird's garantiert besser als die Engine, mit der der "Battlezone"-Klon auf der Hydra gemacht wurde (Screenshot am Anfang diese Threads) - wobei es natürlich auch mal interessant wäre, sich anzuschauen, wie die gemacht ist. Mit Farbe ist es natürlich schon eine Nummer aufwendiger (und cooler).

Nachtrag: Da hat sogar einer dieses Battlezone auf 1024er-Auflösung angepasst:
http://forums.parallax.com/forums/defau ... 3&m=286151

Die Engine verwendet auch mehrere COGs, ist aber wohl sehr spezifisch für dieses Spiel (ein COG zeichnet z. B. nur die Berge im Hintergrund), also keine universelle Vektor-Engine wie die, die wir hier schon fast fertig haben ...

[Janaha]

Der Propeller läuft intern mit 80Mhz, jeder der 8 Cogs, bekommt reihum einmal drann. Die Cogs laufen also "nur" mit 10 Mhz.

Und mal eine ganz laienhafte Frage (ich habe wirklich nicht viel Ahnung von hardwarenaher Programmierung): Wenn ein Propeller es schafft, im Textmodus viel höhere Auflösungen auszugeben, warum braucht er dann für eine Zeile in deinem Modell so lange? Auch beim Textmodus hängt ja kein Grafikprozessor dazwischen, und selbst wenn Tiles verwendet werden, um den Speicherbedarf zu reduzieren, muss ja immer noch jeder Pixel von einem Cog gemalt werden ... Oder verstehe ich da was komplett falsch?

Urgs, hier bin ich noch eine Antwort schuldig geblieben.

Wenn der Propeller im Textmodus ist, dann nutzt er intern einen Videogeneratorteil der die Pixel der Textzeichen im richtigen Tackverhältniss aus einem Schieberegister heraus nacheinander ausgibt. Wenn der Textmodus genommen wird, reduziert sich der Aufwand für die "berechnung" der Pixel enorm, da die Muster der Zeichen im Zeichensatzrom fest vorgegeben sind und mit einem zugriff immer eine ganze Zeile eines Zeichens eingelesen werden kann.

Im Grunde genommen braucht der Propeller im Textmodus nur zwei Zugriffe auf den "Hauptspeicher". Einen um das nächste Zeichen zu lesen und einen um eine komplette Pixelzeile des zu zeichnenden Buchstabens aus dem Rom nachzuladen. Für die Ausgabe schiebt er dann die ganze Pixelzeile eines Zeichens mit nur einem Befehl in das Ausgaberegister, das dann das Videosignal für die nächsten Pixel erzeugt. In der Zeit wo der Videogenerator die Pixelzeile des Zeichens ausgiebt, holt er sich den nächsten Buchstaben und die nächste Pixelzeile aus dem Charakterrom. Dafür reicht ein einzelner Cog vollkommen aus. Der vorteil ist hier einfach, das das Pixelmuster für die Buchstaben fest steht und nicht erst anhand irgendwelcher mathematischen Formeln hergeleitet werden muss.

Bei der Idee mit den oben beschriebenen 2 Bildschirmzeilen an Pufferspeicher für 3D- Garfik würde man sicher einen der Cogs so ähnlich wie beim Textmodus nur dazu hernehmen die aktuelle Bildschirmzeile Punkt für Punkt auszugeben. Das hier beschriebene Problem wäre das befüllen der jeweils nächsten Zeile mit den Punkten der 3D- Grafik. Wie oben beschrieben ist dies leider deutlich aufwändiger als einfach nur Bitmuster aus dem Zeichensatzrom auszugeben.

Grüße
Janaha

[scotty]

Die COG's laufen schneller und bei reinem RISC-Code auch unabhängig vom Hub. Die meisten Befehle werden in vier Takten abgearbeitet (laden, berechnen, speichern und fetch?), d.h. jede COG arbeitet effektiv mit 20 MHz die meisten Befehle ab.

Laut Propeller-Datenblatt (S.9) werden die Assemblerinstruktionen in einer Pipeline abgearbeitet. Solange ein bedingter Sprung nicht verzweigt (die Sprungvorhersage geht von "springe immer" aus) und kein HUB-Zugriff ansteht, fällt also nach dem Füllen der Pipeline in jedem Takt ein Instruktionsergebnis "hinten" raus. Das sollte die Lage bei geschickter Programmierung auch noch etwas entspannen