Maximale mögliche Auflösung / Farbanzahl

[Janaha]

Halloe.

Ich habe mich in den letzten Tagen mal in die Dokumentationen von Paralax zu der Generierung der VGA- Signale eingelesen. Dabei ist mir aufgefallen, das die dort beschriebenen Grafikmodi meist nur sehr stark eingeschränkt mit der erziehlbaren Farbanzahl umgehen können. Die beschriebenen Tile-basierten Modi haben soweit ich das bisher gefunden habe immer eine Einschränkung auf nur 4 verschiedene Farben pro Tile. Was meint ihr, könnte man da mehr rausholen ? Ich würde gern die vollen 64 Fraben in jedem Tile zur Auswahl haben und dafür dann lieber bei der maximalen Auflösung etwas zurück stecken. Dafür bräuchte ich dann auch keine Sprites, naja evtl. einen für den Mauszeiger aber das wär nicht so wichtig.

Ich grüble gerade darüber nach evtl. einen Nethack- Clone zu schreiben, der jedoch eine Tilebasierte Dungeongrafik anzeigen soll. Dafür soll der Grafikprozessor jeweils mit den aktuell benötigten Tiles geladen werden und bei bedarf sollen dann Tiles aus dem "Hauptspeicher" oder von SD- Card kopiert werden. Nun würde ich die Tiles jedoch am liebsten die gesammte mögliche Farbpalette nutzen lassen. Als Grafikmode schwebt mir da einer Mischung als Tilebasierter - Dungeonansicht und Textmode basierend auf dem internen Propellerfont vor. Die Tilegröße steht noch nicht fest, ich denke 16*16 wirds werden, evtl. auch 32*32 aber größer wohl nicht.

Was meint ihr, wäre das machbar oder muss man sich mit 4 Farben pro Tile abfinden ?

Grüße
Janaha

[Rainer]

Hi janaha,

ich habe zu Hause auf dem Rechner zig Grafiktreiber in allen möglichen Auflösungen (bis 1600x1200) von allen möglichen Quellen für den Propeller.
Ich glaube da ist auch einer mit 64 Farben pro Tile oder höher bei VGA Auflösung dabei.
Ich schaue dann mal wenn ich von der Arbeit komme.

Gruß.
Rainer

[EDIT]

Habe gerade beim schnellen suchen einen Treiber mit 320x96 mit 400 Farben (NTSC) entdeckt. Müsste man sich mal ansehen. --> http://forums.parallax.com/forums/defau ... 3&m=195345
[/EDIT]

[EDIT2]
Vergiss den ersten EDIT .. Du wolltest ja VGA.
[/EDIT2]

[Janaha]

Ah Cool,

dann müsste sich das Projekt ja doch so wie ich mir das Vorstelle umsetzen lassen. Wobei der Hive mit seinem 6bit- DA Wandler ( 2 bit Pro Farbe ) ja "nur" 64 verschiedene Farben darstellen kann. Irgendwelche eckligen Interlace-Modi Tricks mal ausgeschlossen.

Ich werde mir demnächst mal schnell nen Converter zusammenbauen, mit dem man 24bit RGB - Dateien im ungepackten TGA- Format passend für den Hive umconvertieren kann. Sollte am Ende wahlweise sowas wie ein RAW-Binary Format und SPIN/Sources generieren können. ( TGA, weil meine 3D- Engine da schon einen passenden Loader für hat. )

Grüße
Janaha

[Janaha]

Iks, da war ich zu schnell mit meiner Antwort was ?

Hihi, ja es sollte die VGA- Ausgabe damit machbar sein. Ich sehe momentan eigentlich nur da Probleme, wo ein COG die VGA- Daten aus dem 32KB Ramblock des Prozessors rechtzeitig nachladen muss, damit er die Pixel rechtzeitig ausgeben kann. Bei bis zu 20 Takten verzögerung im zugriff auf ein Byte Hauptspeicher sehe ich da arge Timingprobleme auf mich zukommen, wenn ich nicht gerade mit ziehmlich breiten Pixeln hantieren möchte. So 320*200 stelle ich mir da als Minimalauflösung schon irgendwie vor.

Grüße
Janaha

[Rainer]

Natürlich nur alles unter Vorbehalt.
Ich habe evtl. Grafiktreiber ... ob die wirklich funktionieren wie gewollt kann ich Dir natürlich nicht sagen.
drohne235 kann Dir dazu bestimmt mehr sagen.

Übrigens kann ich Dir "Gear" nur empfehlen. Einfach mal VGAdemo.spin mit F8 im SpinTool kompilieren, als EPROM-File abspeichern. Dann in Gear laden und das VGA-Monitor-Plugin dazuladen. Ist zwar elend langsam aber man kriegt einen guten Eindruck.

Gruß.
Rainer

[Rainer]

So, habe meine Verzeichnisse mal durchsucht. Leider war ich nicht besonders erfolgreich was VGA-Grafik angeht.
Das, was am ehesten passen würde wäre VGA 512x384. Ist aber auch Tile.
Bei den anderen Treibern ist mir ehrlich gesagt nicht wirklich klar was die genau machen. Interlace, Zeilen übereinanderschreiben, usw.
Gear hilft mir da nicht weiter. Wir müssen wohl warten bis wir den Hive haben und dann rumprobieren.
Aber wenn man mal so schaut was die aus "Hydra" rausquetschen (allerdings im TV-Mode) dann glaube ich geht da schon was. Immerhin ist der Hive die weit überlegenere Maschine.
Wenn man sich den Screenshot vom Startracker mal ansieht kann man sich auch gut vorstellen, das man ein nettes Nethack hinkriegt.

Gruß.
Rainer

[drohne235]

Naja, die Startracker-Oberfläche besteht ja nur aus vergleichsweise groben farbigen Blöcken und nutzt Tiles. Der limitierende Faktor bei VGA ist der RAM - man kann ausrechnen das es bei relevanten Auflösungen schnell recht eng wird. Da haben auch die Amis noch nichts wirklich neues aus dem Propeller gekitzelt und die meisten weichen für Spiele halt auf TV-Modus aus da siech bei geringer Auflösung die RAM-Situation schnell entspannt - der Speicherverbrauch steigt halt quadratisch mit der Auflösung. Und das ist auch ein Grund warum der Hive unbedingt einen TV-Ausgang haben sollte: Auf der einen Seite ist es natürlich ziemlich kultig und retro, aber halt auch entspannend wenn man mal stressfrei ein Game programmieren möchte.

Allerdings ist ja nicht gesagt das es jeder unbedingt stressfrei mag - mancher hat ja eine masochiste Ader. Deshalb mal ein paar Gedanken zur Grafik die mir so gekommen sind - alles nur Fragmente und ohne genaue Prüfung:

- Da Grafik beim Prop nur Software ist kann man theoretisch mit einem passenden Treiber beliebig Modis mischen. Man könnte also einen Teil vom Interface, z.B. am oberen und unteren Rand, aus Tiles aufbauen und so Speicher sparen.

- "Atari-Modus": Speicher ist knapp im Propeller, aber eigentlich haben wir genug im Hive, allerding an Regnatix und damit nicht direkt Bellatrix zugänglich. Aber wer sagt denn das es so bleiben muß, denn sowohl die Aufteilung der Funktionskomplexe wie auch der Bus ist ja auch nur Software!? Nehmen wir mal an in Regnatix läuft eine COG als Speichermanager und adressiert zyklisch unter Anleitung von Bellatrix den externen Ram um diesen als Bildschirmspeicher zu nutzen, würde man so ein hochauflösendes Bild mit maximaler Farbzahl hinbekommen? Probleme dabei: 1. Ist dieser Mechanismus schnell genug in PASM realisierbar? 2. Da die Seichermanager-Cog in Regnatix den Bus zu einem relativ hohen Prozentsatz auslastet muß man alle anderen Zugriffe (z.B. Kommunikation zu Administra und auch die Bearbeitung der Bilddaten selbst) zeitlich synchron koordinieren und in die restliche Zeit "quetschen". Wenn das klappt ist es aber ein ganz schönes Husarenstück und hat mich ein wenig an die Funktion der Atari-Chips ANTIC & GTIA erinnert. Die Speichermanager-Cog wäre dabei Antic und Bellatrix der GTIA. Dem entsprechend kümmert sich der GTIA um die Farbpallette und kann nebenher auch noch Sprites einblenden.

http://picasaweb.google.com/lh/photo/rj ... directlink

- "Vectrex-Modus" - ein anderer Denkansatz: Wir haben in Bellatrix also wenig Speicher um hochauflösende Grafik darzustellen, dafür aber massig Rechenkapazität? Dann lassen wir doch den Bildwiederholspeicher einfach weg und erzeugen unser Bild in Echtzeit! Das geht natürlich nicht um sich normale Fotos anzuschauen, aber gut komprimierbare Bilder wie Vektorgrafik könnte man so erzeugen: Wir haben nur einen Minimalpuffer von einer Bildschirmzeile und eine Raster-Cog welche diese Zeile ausgeben kann. Parallel mit dieser Ausgabe könnte eine/mehrere Render-Cogs entsprechend einer Liste von Vektoren in einem zweiten Zeilenpuffer die nächste Zeile berechnen - und nur diese. Am Ende jeder Bildschirmzeile werden diese beiden Puffer getauscht. Statt einem Bildschirmpuffer hätte man also eine art "Display-List" mit einer Liste von Vektoren die dargestellt werden sollen. Das Verfahren funktioniert mit Sicherheit, wobei allerdings die Frage steht ob die RenderCogs eine genügend große Anzahl Vektoren pro Zeile berechnen können. Das ganze hätte natürlich auch noch andere Vorteile: An einer Vektorliste könnte man recht komfortabel entsprechende Manipulationen ausführen - Objekte zoomen, drehen, bewegen - und das ganze fast (bis auf die zwei Zeilenpuffer) ohne Bildwiederholspeicher. Und man kann sagen was man will - die Vectrex-Grafik war schon irgendwie kultig.

http://picasaweb.google.com/lh/photo/VE ... directlink
http://picasaweb.google.com/lh/photo/mW ... directlink

Ich denke auf dem Gebiet der Grafik ist das letzte Wort noch lange nicht gesprochen... Allerdings sind das nur so spontane Einfälle, keine Ahnung ob das machbar wäre. Zur Überprüfung fehlen auch mir da noch massiv die PASM-Kenntnisse, aber ich arbeite dran. Da ich aber noch nie irgendwelche Grafikdemos oder Games programmiert habe kann ich mir vorstellen das es genug Leute gibt die da noch auf ganz andere Ideen kommen und diese auch viel besser in Software umsetzen können. Wenn ich mir anschauen was so ein Softwarecrack wie Linus “lft” Attkinson aus nur einem Propeller rausholt bin ich da schon grenzenlos beeindruckt.

[Rainer]

Ja, das wird noch interessant.
Ich bin jetzt nicht so der Grafik-Freak, da mir leider die zugrundeliegende Mathematik nicht so leicht von der Hand geht (transformieren, Matrizenberechnung v. Grafik, usw.).
Ich habe mich mal mit Parallax-Scrolling auf dem Atari ST beschäftigt (Stripe Methode) .. später auf dem Amiga mit Layertechnik (Blitter machts möglich ).
Auch mit "Redraw-Methoden" für grafische Benutzerführungen mit Fenstertechnik.

Nur so mal frei vor mich "hingesponnen":
Wenn man weiß was der limitierende Teil der Kette ist (Busgeschwindigkeit oder Prozessor(en)) kann man verschiedene Ansätze fahren.

-- Ist der Bus überfordert könnte man versuchen die Bildaten komprimiert vorzuhalten und auch komprimiert über den Bus zu schicken und dafür ein paar Cog's zum dekomprimieren in's Rennen zu werfen.

-- Mann könnte auch Tokens entwerfen .. warum soll man einen blauen Hintergrund Byteweise über den Bus schicken, wenn man auch "Hintergrund, blau" schicken kann und der Propeller weiß was er tun muß (ist ja in ios.sys schon teilweise so integriert)

-- Bei geschickter Programmierung kann man vll. mehrere Cog's gleichzeitig auf das Videosignal loslassen. Ich weiß nicht ob das technisch geht, aber soweit ich das sehe sind alle Cog's mit dem Videogenerator verbunden. Wenn man jetzt den Bildschirminhalt z.B auf 4 Cog's aufteilt, kann sich jeder nach einem viertel des Bildschirmaufbaus wieder mit Daten versorgen, während die anderen 3 "weiterzeichnen"

-- Mit einer Voxel-Engine kann man riesige 3D-Landschaften mit geringem Speicherverbrauch erzeugen.

-- Statt Sprites kann man auch BOB's einsetzen .. also das Objekt mit dem Hintergrund logisch verknüpfen .. macht den Spriteerzeugenden Cog frei für andere Aufgaben und BOB's bieten auch mehr Möglichkeiten als Sprites.

Hängt natürlich immer vom Spiel / Anwendung ab, was das Beste ist.

Wie gesagt .. alles nur Theorie. Wahrscheinlich wird mich die Wirklichkeit schnell wieder auf den Boden der Tatsachen ziehen

Gruß.
Rainer

[laserjones]

Eine echte Vektor-Engine wäre natürlich ultracool. Damit wäre der Schritt zur 3D-Engine (Wireframe mit echtem Retro-Look, "Elite" lässt grüßen ...) auch nicht mehr weit. Von der reinen Rechenleistung her sollte das wohl problemlos machbar sein. Leider besitze ich dafür aber auch nicht die nötigen Kenntnisse ...

[Rainer]

Eine echte Vektor-Engine wäre natürlich ultracool. Damit wäre der Schritt zur 3D-Engine (Wireframe mit echtem Retro-Look, "Elite" lässt grüßen ...) auch nicht mehr weit. Von der reinen Rechenleistung her sollte das wohl problemlos machbar sein. Leider besitze ich dafür aber auch nicht die nötigen Kenntnisse ...

Du meinst sowas ?
Ist auf einer Hydra programmiert ... und die hat nur 1 Propeller, nicht 3




Hier ein Film. Da sind 2 Hydra's miteinander verbunden. Das Programm ist Netzwerkfähig, hat aber keine KI und ist somit nicht Solo spielbar.
http://www.finitesite.com/mpark/bz.wmv

Hier der Source:
http://forums.parallax.com/forums/defau ... 3&m=221357

"Einfach" an den Hive anpassen und los gehts

Gruß.
Rainer