Maximale mögliche Auflösung / Farbanzahl

[Rainer]

@laserjones:
Your dream becomes true

http://www.youtube.com/watch?v=XNPDslLv ... re=related

[digger]

Also das Oszi-Demo is ja mal Hammer ... das man sowas hinbekommt hätte ich nicht gedacht.

[Janaha]

Halloe.

Wie das ganze aussehen würde, wenn man auf den Bildspeicher verzichtet und statt dessen bei jedem Pixel schaut, ob evtl. ein 3D- Objekt darunter liegt, das möcht ich hier lieber nicht schätzen.

Naja, wenn man sich auf Wireframe beschränkt bräuchte man ja keinen Test in der Z-Achse, da werden alle Punkte einfach geodert. Wenn man einen schnellen Linienalgorithmus hätte, welcher die Linien von oben beginnend immer in Echtzeit zeilenweise berechnen könnte, könnte man bis auf den Puffer für zwei Zeilen ganz auf einen Bildschirmpuffer verzichten und könnte den frei werdenden Speicher in Bellatrix mehr für Routinen nutzen, welche genau diese inien manipulieren (drehen, strecken, bewegen...)

Hm,

bei Wireframe hätte ich das ganze eh immer "geodert" oben drauf malen lassen, selbst mit Bildpuffer. Der immer wieder gern genommene Bresenhamalgorithmus braucht zum arbeiten bloss die beiden Eckpunkte einer Linie. Alles dazwischen wird mit einfachen Integer-Funktionen berechnet. Man muss bloss noch die 3D- Koordinaten seiner Objekte auf die Kamerasicht und den 2D- Bildschirm umrechnen. Wenn man dann noch auf den Bildspeicher verzichtet und nur jeweils eine Zeile Bildspeicher nutzt. Wäre das ganze sicher machbar. Es würde dann nur noch von der Anzahl gleichzeitig zu malender Linien abhängen. Ich denke hier wäre das schliemmste eigentlich nur, die Umrechnung der 3D- Welt auf die 2D- Linienansicht zu machen. Das könnte ja eigentlich auch immer noch einer der anderen beiden Prozessoren mit unterstützen. Hier überlasse ich euch gern das Feld. Sagen wir einfach mal ein C64 hats hinbekommen (ELITE und co.) also muss das der Hive auch können.

Einen Zugriff auf das externe Ram sehe ich da auch eher als sinnlos an, denn der ist viel zu langsam und auch noch am "falschen" Chip drann. Das extere Ram werde ich wohl eher dafür nehmen, um dynamisch Tiles/Sprites nachzualden. Und dann nur die gerade wirklich gebrauchten Tiles/Sprites im Ram des "Videopropellers" zu halten.

Ist der RAM an Regnatix wirklich falsch? Für Anwendungen wie Compiler, Editoren usw. ist der Speicher natürlich genau richtig. Aber die Frage habe ich mir auch schon gestellt wenn es um Grafik geht. Und es erscheint auch wirklich an der falschen Stelle, zumindest wenn man die Struktur des Hive so als fertig ansieht. Aber das muß ja nicht so sein! Du brauchst den eRam an Bellatrix? Dann programmiere den Hive so das es genau so ist: Mache eine COG in Regnatix zu einem "externen" Adresszähler/Register für Bellatrix, die adressierte Speicherzelle kann Bellatrix selbst über den Datenbus einlesen. Im Extremfall kann Bellatrix über eine umkonfigurierte Steuerleitung (PRO/SELECT) den "Adresszähler" in Regnatix takten, kann also den Zugriff auf den Speicher selbst steuern. Wenn du also möchtest, mache Regnatix einfach zu einem Speicherkontroller für Bellatrix.

Nein, nein der Ram ist auf keinen fall an der Falschen stelle. An den Videochip passt er so ja eh nicht mehr, weil er viel zu viele Adress- und Datenleitungen braucht. Das Ram brauchen wir vor allem für die laufenden Anwendungen.

Im momemt schwebt mir da vor, das bei dem Start einer Hive- Anwenung die Anwendung aus einer Bibliothek einen Video/Audio- Treiber auswählen darf, der dann auf den Video/Audiochip sozusagen nachgeladen wird.

Momentan ist es so: Eine Anwendung kann über die IOS-Funktionen "breset/bload" in einem Programm einfach einen kompletten neuen Code in den Bellatrixchip laden und damit seinen eigenen Grafiktreiber aktivieren. Für die Kommandozeile als momentanes einfachste Oberfläche wird einfach wieder der normale Standarttreiber "vga.bin" in Bellatrix geladen - momentan ein schöder Texttreiber. Im StarTracker mache ich das schon genau so, dort wird beim starten der Treiber geladen um die Startrek-Oberfläche zu zeichen und beim beenden wird wieder der Texttreiber geladen. Die Bibliothek sind dabei einfach die entsprechenden Treiberdateien auf der SD-Karte, im Fall des StarTrecker befindet sich der Treiber in der Datei "stint.bin". So hatt jede Anwendung uneingeschränkt die volle Kontrolle über die Ressourcen von Bellatrix.

Was noch fehlt: Das gleiche für den Administrachip. Mir ist einfach noch keine einfache Methode eingefallen wie man das für Administra hinbekommt, da sich ja in diesem Chip etwas ganz grundlegendes befindet: Die Anbindung an die SD-Card, von welcher ja die Treiber kommen. Man müßte also den Treiber beim Wechsel erst im eRam puffern oder irgendwie die Dateien umkopieren, aber das erschien mir bisher einfach zu umständlich. Aber Fakt ist eins: Letztlich brauchen wir das auch für Administra, genau wie du das schreibst.

Ich hatte mir da überlegt, das RAM der Cog's gezielt aufzuteilen zwischen den Teilen die eine Anwendung nutzen darf und teilen, die fest dem Betriebssystem gehören. Das Betriebssystem wird dann entsprechende Routinen haben, die teile des internen Rams jederzeit mit neuen Daten / Programmen füllen kann. Natürlich auch mit entsprechenden möglichkeiten den geladenen Code zu starten. Die Aufteilung wieviel Platz auf jedem Chip für die Anwendungen frei sind, hängt dann von dessen Aufgaben und der größe der Betriebssystemroutinen ab. Wenn man nicht immer den ganzen Chip neu laden muss, kann sich auch der Administra selbst mit neuen Funktionen versorgen. Sozusagen für den Vollausbau schweb mir ein eigener Compiler sammt Editor vor mit dem man direkt auf dem Hive entwickeln kann und der auch die Mehrkernfähigkeiten optimal unterstützen sollte. Daher denke ich auch an Assembler, das könnte der Compiler leicht selbst generieren. Für Pascall habe ich schonmal sowas gemacht und ich denke, das ließe sich für den Hive umbauen.

Genau Deine Idee hatte ich auch .. außerdem hätte ich noch gerne eine Funktion, um die aktuelle Auflösung abfragen zu können.

Jo, wichtig wären auch Auskunftsfunktionen - Anzahl der Zeichen und Zeilen des aktuellen Treibers - um zeichenorientierte Software unabhängig von der Auflösung zu programmieren. Bis jetzt hat das System ja noch "Werkstattniveau", d.h. ich hab einfach nur das eingebaut was ich aktuell brauchte - da ist also evtl. noch viel Bedarf an Funktionalität. Vielleicht wäre es ja auch besser das ganze einfach nochmal neu anzufangen.

Was ich irgendwie bei der Grafik absolut cool finde ist die alte Vectrex:

http://www.retrozentrale.net/?p=1266
http://vectorzoa.com/info2.html

Bei so einer einfachen Grafik muß man sich auch mehr auf das Spiel selbst, auf innovative Ideen konzentrieren, die dann ihren ganz eigenen Reiz haben.

Hihi.

Ja die Vectrex, die hatte schon was besonderes. Hier wurde der Elektronenstrahl nicht Zeile für Zeile über den Bildschirm geführt, sondern die Anwenung hat ihn den Vectoren der 3D- Grafik entsprechend geführt. Soweit lassen sich die einfachen Fernseher und TFT Monitore leider nicht verbiegen. Die arbeiten immer ganz star Zeile für Zeile ab.


Grüße
Janaha

[drohne235]

Ja die Vectrex, die hatte schon was besonderes. Hier wurde der Elektronenstrahl nicht Zeile für Zeile über den Bildschirm geführt, sondern die Anwenung hat ihn den Vectoren der 3D- Grafik entsprechend geführt. Soweit lassen sich die einfachen Fernseher und TFT Monitore leider nicht verbiegen. Die arbeiten immer ganz star Zeile für Zeile ab.

Einen echten Vektorbildschirm bekommen wir natürich nicht hin, aber ich denke da mehr an die dynamischen Eigenschaften: Da die Vectrex ja jedes Bild dynamisch in Echtzeit aufbaut, würde eine zeilenweise Echtzeitberechnung in dieser Eigenschaft der Vectrex entsprechen. Und ich finde so ein simulierter "Vectrex-Mode" würde nicht nicht nur den Vorteil bringen, so gut wie keinen Bildwiederholspeicher zu brauchen, sondern die Art der Grafik finde ich auch sehr inspirierend: Nur reine Vektoren. Da muß man schon sehr innovative Gedanken entwickeln um ein Game zu realisieren, hätte dadurch aber auch einen ganz unverwechselbaren Stil. Nehmen wir mal irgendwelche Animationen: Nicht vollflächige Pixelanimationen, sondern reine Vektorfilmchen. Wer kennt noch dieses berühmte Strichmänchen aus dem Fernsehen:

http://www.youtube.com/watch?v=4MsGCZhqYaY
http://www.youtube.com/watch?v=vZBZCBAhv7c
http://www.youtube.com/watch?v=VAwjTaN9mI4

Sowas ist doch viel kultiger als jedes bestehende 3d-Game auf dem PC und noch endlos ressourcenschonender, wenn man dafür eine Engine für Bellatrix hätte. Was könnte man damit alles realisieren?

http://www.muttis-faust.de/link.htm

Was ich damit meine ist folgendes: Es muß ja nicht physisch genau und exakt wie bei der Vectrex sein, aber mit einer entsprechenden Engine könnte man wirklich tolle und einmalige Sachen machen welche an den Vectrex-Gedanken anknüpfen und ihn weiter entwickeln. Und genau deshalb ist der Hive ja auch Retro-Style und nicht Retro, er ist halt kein Nachbau eines Atari, C64 uder einer Vectrex (in alphabetischer Ordnung , sondern er fühlt sich so an und kann davon ausgehend darüber hinaus gehen.

[laserjones]

Boah, ich krieg hier echt den Overflow! Aufhören, mein Kopf platzt!

Also langsam glaube ich wirklich das wir hier alle gleich verrückt sind - da hab ich auch schon dran gedacht. Wäre natürlich absolut Steampunk so ein halbmechanischer Laservektorbildschirm.

"Steampunk" ... Den Begriff kannte ich noch gar nicht, und was man alles zu sehen kriegt, wenn man das in der Google-Bildsuche eingibt ... Und was man bei YouTube alles an irren Oszilloskop-Missbräuchen und Laserprojektionen findet ... Hilfe, ich will drei Leben, und zwar alle parallel! (Hm, müsste mit dem HIVE und seinen drei CPUs doch eigentlich gehen ...)

Und gleichzeitig schlägt die ganze Zeit mein "Sinnwächter" im Hinterkopf Alarm und erinnert mich daran, dass mein erstes Leben schon gerammelt voll ist und ich auch noch Geld verdienen muss ... Ich muss mir ganz schnell eine "sinnvolle" Anwendung für den HIVE ausdenken, um das Ganze vor dem Wächter (und meiner Familie) zu rechtfertigen.

Wer kennt noch dieses berühmte Strichmänchen aus dem Fernsehen:

Ich glaube auch, dass uns wirklich die gleichen Sachen faszinieren. Das macht Spaß, auf verwandte Geister zu treffen, denen intelligente, originelle, ästhetische und effiziente Lösungen wichtiger sind als die übliche Bombastik. Und die nicht immer auf den "Sinn vons Ganze" schauen.

[Rainer]

Ich glaube auch, dass uns wirklich die gleichen Sachen faszinieren. Das macht Spaß, auf verwandte Geister zu treffen, denen intelligente, originelle, ästhetische und effiziente Lösungen wichtiger sind als die übliche Bombastik. Und die nicht immer auf den "Sinn vons Ganze" schauen.

Schön gesagt und ganz meine Meinung.
Am meisten Spaß haben schon immer Sachen die gemacht, die vollkommen Zweckfrei waren

[Janaha]

Halloe.

Ich habe das mal ein wenig durchdacht mit der Vektorgrafik. Also vorausgesetzt, das man nur 2 Bildschirmzeilen im Ram hält. ( Eine die ausgegeben wird und die nächste Zeile, die gerade gezeichnet wird.). Dann müsste man es ja schaffen, die nächste Zeile in der Zeit zu füllen, die die erste Zeile für ihre Ausgabe braucht. Einen dafür etwas abgewandelten Bresenhamalgorithmus habe ich mir mal schnell auf ein Blatt papier aufgepinselt. Ich bräuchte pro zu zeichnendem Pixel ca. 17 Assemblerinstruktionen. ( ca. weil ich das Propeller Datenblatt hier nicht zur hand habe . Dabei habe ich noch gänzlich das Setup for der Schleife ausgelassen, die die Pixel malt. Das würde ich während der Austastlücke machen, wo der Strahl des Monitors in die nächste Zeile springt.

Der Schlimmstmögliche Fall, den man berücksichtigen müste, wäre eine komplett Horizontale Linie, die die ganze nächste Zeile füllt. Das würde dann bedeuten, das der Cog, der das gerade durchrechnet für jedes Pixel das er zeichnet nur genausoviel Zeit hat, wie die das Pixel im gibt, das in der Zeile darüber gerade ausgegeben wird. Ich weiss ich bin da gemein zu ihm. Das würde bedeuten, das er 17mal scheller sein muss als der Pixeltakt.

Bei einer Auflösung von 640*480 bei 60HZ ( VGA Standard den TFT's problemlos schaffen) ist der Pixeltak 25,175 Mhz. Der Propeller läuft intern mit 80Mhz, jeder der 8 Cogs, bekommt reihum einmal drann. Die Cogs laufen also "nur" mit 10 Mhz. Mist, hier fehlen also schon 15,175 Mhz zur vollendung und ich brauche mindestens 17 Assemblerinstruktionen pro Pixel. ( Ich hoffe ich liege da in meiner Interpretation des Datenblattes nicht falsch. ) Ich nehme erstmal an, das alle Instruktionen nur einen Tack brauchen, da ich keine float- Zahlen verwende. Alles rein Integer basiert und nutzt nur Zuweisungen, Addition, Subtrktion, Vergleiche und Sprünge.

Ich muss also die Auflösung reduzieren. Bei 320 * 240 kann ich den Pixeltakt für den Neuaufbau der nächsten Zeile vierteln. Jedes Pixel meiner 640 Pixel pro Zeile gebe ich einfach doppelt aus und jede Zeile auch einfach 2 mal. Damit kann ich dann den TFT immer noch mit 640*480 @60HZ betreiben, was ihn immer noch glücklich macht.
Damit sinkt die Rate mit der ich die Pixel generieren muss auf 6,29xxMhz. Das würde aber gerade erst reichen um eine meiner 17 Assemblerinstruktionen auszuführen. Für diesen hier dargelegten schlimmsten Fall muss ich also noch 17 mal kleiner werden mit der möglichen Auflösung. Und ich habe erst eine einzige Linie gezeichnet. Wir wollen aber wohl bei der 3D- Grafik deutlich mehr oder ?

Hier breche ich dann meine Berechnungen erstmal ab, da ich mit der Auflösung nicht weiter runter gehen möchte. Wenn man also den schlimmsten Fall nicht einfach ignorieren möchte, würde ich sagen ist nicht so einfach machbar.
Daher sehe ich das ganze mit einem Einzeiligen Puffer als eher unschön an. Wenn ich meinen Hive zusammengebaut habe, werd ich mir die Idee mal näher anschauen. Evtl. läßt sich da ja doch noch was machen.

Grüße
Janaha

[laserjones]

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

Sicher? So wie ich es verstehe, läuft jeder Cog unabhängig von den anderen mit den vollen 80 MHz. Ein Befehl braucht 4 Takte, also haben wir 20 Mips pro Cog.

Siehe z. B. http://www.xgamestation.com/phpbb/viewtopic.php?t=3867 - im Parallax-Forum habe ich die gleiche Aussage gefunden, und im Datenblatt finde ich beim Überfliegen auch nichts Gegenteiliges.

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?

[drohne235]

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.

Ich dachte mir das folgendermaßen: Eine Cog gibt die aktuell fertig berechnete Zeile aus - nennen wir sie mal die ShifterCog. Eine oder mehrere weitere Cogs berechnen die nächste Zeile, die nennen wir mal RenderCog. Diese machen das mit einem zeilenorientierten Linienalgorithmus. Wenn eine Cog zu wenig gleichzeitige Linien pro Zeile schafft könnte man einfach eine weitere Cog verwenden und wie in einer Pipeline das Ergebnis dann zur fertigen resultierenden nächsten Zeile odern.

Ich habs mal anders gerechnet:

h-freq: 31,469 khz = 31,25 ysec
v-freq: 59,94 hz

80 mhz takt
4 takte pro instr. = 50 nsec

31 ysec pro zeile = 31000 nsec pro zeile = 620 instruktionen pro zeile

Wenn ich mich nicht vertan hab haben wir also 620 Instruktionen Zeit pro Cog um die nächste Zeile zu berechnen. Beachten muß man allerdings das die Zugriffe auf den HUB-Ram länger dauern als 4 Takte (7..22 Takte, je nach Zustand des Hubs) aber man könnte gleich komplette Longs in den Hub schreiben. Um den Zugriff auf den Hubram zu reduzieren könnten vielleicht (sofern genug Platz dafür ist) die Cogs die Vektorlisten in ihrem Cogram halten und beim Bildsynchron mit dem Hubram abgleichen.

Eine Cog bräuchte man noch für Maus/Keyboard, eine weitere für den Kommandointerpreter, welcher mit Regnatix kommuniziert. Alle weiten Cogs könnten entweder RenderCogs sein oder sowas wie FXCogs, welche Manipulationen an den Vektorlisten durchführen.

Ist jetzt nur mal so überschläglich, keine Ahnung ob man das in PASM so hinbekommt.

[Janaha]

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

Sicher? So wie ich es verstehe, läuft jeder Cog unabhängig von den anderen mit den vollen 80 MHz. Ein Befehl braucht 4 Takte, also haben wir 20 Mips pro Cog.

Hm, das würde das ganze schon ein bissel Entspannen.

Ich habe wie geschrieben hier kein Datenblatt zur Hand. Habe mich auf das Bild bezogen, nachdem jeder Cog reihum einmal auf die 32KB Hauptspeicher zugreifen darf. Wenn der Cog intern seine Instruktionen sozusagen mit 20Mhz (Mips) statt mit den von mir genommenen 10Mhz schaft würde das ja schonmal die Anzahl der möglichen Assemblerbefehle pro Pixel wieder verdoppeln. Und ganz klar, ich habe nur den wirklich schlimmstmöglichen Fall aufgezeigt. Im gegensatz dazu würde der optimalste Fall ( Vertikale Linie ) ja nur 17 Assemblerinstruktionen pro Bildschirmzeile verbrauchen. Hätte man nur vertikale Linien, könnte man praktisch ca. 32-35 Linien pro Cog hinbekommen, die gleichzeitig in einer Zeile gemahlt werden dürften. In der realität denke ich wird die Anzahl der Linien irgendwo zwischen 1 und 30 pro Cog liegen. ( Ich weiss ist ne blöde schätzung. )

Auch könnte man auf beide Fälle noch geziehlt eingehen und den Aufwand für das Zeichnen von Horizontalen und Vertikalen Linien weiter reduzieren. Für komplett Horizontale Linien könnte man z.B. eine einfache Zählschleife mit nur 4 Assemblerinstruktionen bauen. Außer acht lassen Darf man den Schlimmstmöglichen Fall leider nicht, da viele Linien wie z.B. der Horizont exakt Horizontal verlaufen. Es sei den man neigt den Kopf . Auch würde ich mehr als einen Cog für das füllen der jeweils nächsten Zeile nehmen, mit jedem weiteren Cog kann man die Anzahl möglicher Vektoren in einer Zeile verdoppeln. Bin mal gespannt, wer als erster eine tolle Vectorgrafik mit nur 2 Bildzeilen Puffer hin bekommt.

Und es muss ja auch nicht unbedingt Bresenham sein, evtl. fällt hier ja jemandem noch etwas schnelleres ein, was die Bedingungen (2 Zeilen Puffer) besser unterstützt.

Grüße
Janaha