Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
So siehts aus. bei CGFX und P96 ists so, daß WritePixelArray() bei passendem Format der Grafikdaten einfach ein MemCopy() durchführt, viel schneller geht nur mit handoptimiertem Assembler und direktem Zugriff aufs Video RAM. Warum man das vermeiden sollte, muß ich, glaub ich, nicht erklären, oder?

---

Man sollte vor allem unabhängig von der Frage, ob die momentan betrachtete Hardware das so macht, berücksichtigen, daß manche Systeme den entsprechenden Transfer von der Grafikkarte und nicht vom Prozessor erledigen lassen könnten.
Und dann kann der Assembler-Code noch so handoptimiert sein, gegen ein Busmaster-Transfer kommt er nicht an.

---

Naja, das stimmt schon, und müßte den Leuten auch einsichtig sein, sobald die sich in der Materie etwas besser auskennen. Allerdings gings hier hauptsächlich um Amiga und MaxonBasic, da kann man dieses Thema ruhigen Gewissens etwas vernachlässigen

Zitat:

---

Deshalb ist auch ein Transfer ohne Konvertierung besser. Nicht weil sie Zeit kostet (meist kann sie parallel ausgeführt werden), sondern weil manch ein Chip möglicherweise Direkttransfers unterstützt, aber keine Pixelformat-Konvertierung in Hardware besitzt. Und somit die Frage Konvertierung oder nicht über die Frage Hardwarebeschleunigung oder nicht entscheidet.

---

Siehe oben. In MaxonBasic dürfte parallel ausgeführte Konvertierung ein wenig kompliziert werden Ansonsten hast Du natürlich Recht, wobei das Arbeiten mit mehreren Tasks (Konvertierung/Transfer) nicht unbedingt jedermanns Sache ist

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Also erst das Pixelformat des geöffneten Screens ermitteln und dann dementsprechend per AllocBitmap() eine Bitmap basteln lassen, die später die geladenen Bilddaten im dem Screen genehmen Format enthält.

---

Zu kompliziert. Zu genau diesem Zweck gibt es ja "friend bitmaps". Beim Anlegen der Offscreen-BitMap die Screen-BitMap angeben und gut is.
Das reale Pixelformat überprüft man nur, um herauszufinden, ob es zu den direkt unterstützten Formaten, wie eben BGR (wenn die Bild-Daten ohnehin schon so vorliegen) gehört, oder ob man den Umweg über RGB geht.

---

Stimmt schon, aber was ist da unkomplizierter? Sicher kann man auch die friend BitMap-Option verwenden, aber das Pixelformat überprüfen muß man eh, wenn man nicht nur einen GraKa-Typ unterstützen will. Wenn Ralf dann sowieso schon "weiß", welches Format die Bitmap haben muß, kann er das doch auch direkt statt via friend BitMap angeben. Der Effekt ist der Gleiche. Die Menge an Funktionsaufrufen bleibt gleich und sogar die Funktionsaufrufe selbst sind die gleichen. Nur die Parameter und der Programmfluß sind etwas anders.

Dafür hat er alles Notwendige in einer Funktion, die das in einem Abwasch erledigt und nur noch das Pixelformat als Rückgabe-Wert liefert. Den kann er dann für die Konvertierung nutzen, falls nötig.

Normalerweise würde ich den von Dir genannten Weg auch bevorzugen, weil man dabei das Pixelformat als Blackbox betrachten kann. In diesem Fall muß Ralf aber doch genau erfahren, welches Pixelformat für die Konvertierung benötigt wird, da bringt das Blackbox-Konzept wenig. Ganz abgesehen davon, daß er in MaxonBasic programmiert


@Ralf:

Tschuldige, daß das Ganze hier etwas in C-Sprachkonventionen ausartet, aber AmigaOS hat C halt "lieb" Wenn Du da Fragen haben solltest, kannst Du die ja problemlos hier oder per Mail stellen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Zitat:

---

Tschuldige, daß das Ganze hier etwas in C-Sprachkonventionen ausartet, aber AmigaOS hat C halt "lieb" Wenn Du da Fragen haben solltest, kannst Du die ja problemlos hier oder per Mail stellen.

---

Das macht nichts. Die meisten MaxonBasic-Demos die ich hier habe verstehe ich nicht auf Anhieb, weil sie für mich aussehn wie C-Quellcode. Ich denk mir mal das ihr diese MaxonBasic-Programme schneller lesen könnt als ich.
Z.b. wird da auch hin und wieder ein HOOK (wieso denk ich da an Peter Pan? ) eingerichtet und ich hab kein Plan was abgeht.


Ich bin halt auf AmigaBasic, OS1.2-Ebene und wurde vor kurzem auf eine Zeitreise Richtung Zukunft(OS3.1) gegangen und versteh halt net alles.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Tschuldige, daß das Ganze hier etwas in C-Sprachkonventionen ausartet, aber AmigaOS hat C halt "lieb" Wenn Du da Fragen haben solltest, kannst Du die ja problemlos hier oder per Mail stellen.

---

Das macht nichts. Die meisten MaxonBasic-Demos die ich hier habe verstehe ich nicht auf Anhieb, weil sie für mich aussehn wie C-Quellcode. Ich denk mir mal das ihr diese MaxonBasic-Programme schneller lesen könnt als ich.
Z.b. wird da auch hin und wieder ein HOOK (wieso denk ich da an Peter Pan? ) eingerichtet und ich hab kein Plan was abgeht.


Ich bin halt auf AmigaBasic, OS1.2-Ebene und wurde vor kurzem auf eine Zeitreise Richtung Zukunft(OS3.1) gegangen und versteh halt net alles.

---

Das hat nur etwas mit systemnaher Programmierung zu tun und nichts mit BASIC oder C. In dem speziellen Fall "Pixelformat" ist es sogar hardwarenahe Programmierung. Das Pixelformat braucht dich auch in C normalerweise nicht zu interessieren. Du hast dir einfach das "falsche" Projekt ausgesucht.

Tschüß,

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von NoImag:

Das hat nur etwas mit systemnaher Programmierung zu tun und nichts mit BASIC oder C. In dem speziellen Fall "Pixelformat" ist es sogar hardwarenahe Programmierung. Das Pixelformat braucht dich auch in C normalerweise nicht zu interessieren. Du hast dir einfach das "falsche" Projekt ausgesucht.

---

Naja, er denkt da wohl auch (genau wie ich ) mehr an das Zeiger-Hantieren, daß ja nicht unbedingt BASIC-typisch ist. Auch in BlitzBasic2 sehen die Sourcen mehr nach C-Code aus als nach BASIC, wenn man systemnah programmiert. Für C-Programmierer, die ein bißchen Information aus den Sourcen gut gebrauchen könnten, ist das hingegen recht praktisch, weil leicht lesbar

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Ok, also mal sehn. Wie geh ich jetzt am besten vor:

1. prüfen ob BGR-Screen möglich ist und wenn ja, diesen auch benutzen.
2. Wenn ausgewählter Screen kein BGR-Screen ist, dann Daten konvertieren.
3. Daten im Feld (AllocBitmap) ablegen
4. Mit Clipblit kopieren

Kommt das so etwa hin?

PS: 5. Speed testen.


Punkt 1 macht mir da noch etwas Kopfzerbrechen. Das ganze kann ich wohl mit dem ASL-Request nicht lösen.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Ok, also mal sehn. Wie geh ich jetzt am besten vor:

1. prüfen ob BGR-Screen möglich ist und wenn ja, diesen auch benutzen.
2. Wenn ausgewählter Screen kein BGR-Screen ist, dann Daten konvertieren.
3. Daten im Feld (AllocBitmap) ablegen
4. Mit Clipblit kopieren

Kommt das so etwa hin?

PS: 5. Speed testen.


Punkt 1 macht mir da noch etwas Kopfzerbrechen. Das ganze kann ich wohl mit dem ASL-Request nicht lösen.

---

Laß den Punkt 1 einfach weg, der ist mehr als flüssiger

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Flüssiger? Ich will Speed!

Wie kann ich eigentlich Prüfen welchen Farbformate möglich sind?
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Flüssiger? Ich will Speed!

---

Mehr als flüssiger. Überflüssig . Der Extra-Test auf BGR ist redundant, wenn die verwendete GraKa den nicht beherrscht. Dann mußt Du sowieso erst einmal ermitteln, welches Pixelformat die GraKa verwursten kann. Wenn Du den Test auf BGR da gleich mit einbaust, hast Du ein paar Zeilen Code gespart

Zitat:

---

Wie kann ich eigentlich Prüfen welchen Farbformate möglich sind?

---

Meines Wissens nach gibts dafür keine spezielle Funktion. Eine (theoretische) Möglichkeit wäre, dem Screenrequester der Reihe nach alle Pixelformate als Filterkriterium mitzugeben und die sich ergebenden Listen auszulesen. Das wäre aber alles andere als elegant

Kümmer Dich nicht so sehr darum, was Du alles vor der Konvertierung in Erfahrung bringen kannst, das ist unnötiger Aufwand. Die Ermittlung des Pixelformats ist keine große Sache (GetCybBitmapAttr()) und Konvertieren bleibt Dir, wenn die GraKa nicht mitspielt, sowieso nicht erspart

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von DariusBrewka:
Ralf, lass dein ganzen krempel einfach weg und überlege dir wie du intern deine Daten behandeln wirst, es bringt nichts die Daten irgendwie zu konvertieren und dann immer wenn man etwas ändern will, die Algorithmen die das erledigen auf die verschiedenen Formate umzuschreiben. Der Amiga ist so effizient, weil es für viele Probleme schon lösungen gibt und die liegen in Libraies vor, lass dein Tool einfach schnell sein und da kannst du auch kompromisse eingehen. Nutze die guigfx.library oder beschränke dein Tool darauf dann halt nicht überall laufen lassen zu müssen.

---

Hm, Du hast aber schon gelesen, worum es Ralf geht, oder? guigfx und render.library kann er sich da genauso sparen, da CyberGraphX bereits die entsprechende Konvertierung vornimmt, wenn nötig. Da das aber während des Transfers geschieht (genau wie bei der guigfx/render.library), ist die Darstellung etwas langsam. Er versucht, ein 24Bit-Bild _möglichst schnell_ auf den 24Bit-Screen zu bekommen.

Was sagt uns das? 24Bit = RGB oder BGR oder... (je nach GraKa). Liegen die Daten nicht im passenden Pixelformat für die GraKa vor, ist Konvertierung des Pixelformats fällig. Allerdings nur in der Reihenfolge der Bytes des 24Bit-Wertes. Da braucht er keinen Riesen-Aufwand an Konvertierung zu treiben sondern muß nur dafür sorgen, daß die einzelnen Bytes in der richtigen Reihenfolge im Speicher landen. Das kann er bequem und schnell während des Ladens erledigen und muß dafür nicht unbedingt auf externe Libraries zurückgreifen. Der darauf folgende Transfer zur GraKa ist intern dann nur noch ein simples MemCopy() und das ist die schnellste Lösung, die noch systemkonform ist.

Sobald er allerdings versucht, die Bilder in andere Farbtiefen umzurechnen, würde ich ihm auch guigfx empfehlen. Aber darum gehts ihm vorerst ja nicht.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Hm, Du hast aber schon gelesen, worum es Ralf geht, oder? guigfx und render.library kann er sich da genauso sparen, da CyberGraphX bereits die entsprechende Konvertierung vornimmt, wenn nötig. Da das aber
...

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von DariusBrewka:

Zitat:

---

Hm, Du hast aber schon gelesen, worum es Ralf geht, oder? guigfx und render.library kann er sich da genauso sparen, da CyberGraphX bereits die entsprechende Konvertierung vornimmt, wenn nötig. Da das aber
...

---

Natürlich habe ich dass, nur macht es sich IMO zu viele gedanken um Speed, wozu?.

Ralf will ein speziellen ImageViewer programmieren, welcher übergrosse Images anzeigen kann unter Umgehung der Datatypes. Es wird Ralf nicht einfach gelingen dieses auf mehr als einige Formate auszudehnen, AFAIK geht's ihm um BMPs, welche im BGR Format vorliegen. Sollte Ralf darauf Wert legen, diese Images auch auf Fremden Screens darzustellen, bleibt ihm nichts anderes übrig, sich um die ganzen Konvertierungen&Co zu kümmern. Will er einen eigenen Screen, ist das Alles viel einfacher, er kann einen CGX Screen in dem gewünschen Format anfordern und über die CGX Funktionen die Adresse des Bildschirmspeichers besorgen und direkt das Bild dahin entpacken ganz ohne Konvertierungen.

Ich habe die gleichen Probleme auch vor kurzem gehabt und habe für mich die einzig vorstellbare Lösung gefunden. Speed steht an zweiter stelle, die Einfachheit sollte vorrang haben, erst wenn Alles so geht wie es soll, kann man sich über ersteres gedanken machen.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Und genau deswegen, meine ich, ist es am sinnvollsten, beim Laden der Bilddaten bereits die passende Byte-Reihenfolge im Speicher abzulegen. Macht man das so, daß ein Byte geladen wird, überprüft, an welche Stelle im Speicher es stehen muß und es dann auch einzeln zur GraKa überträgt, wirds gnadenlos langsam (min. 1 kompletter Zorro-Zyklus für 1 Byte. Aua! ).

Die "Konvertierung" in die jeweils passende Byte-Reihenfolge ist wirklich nicht schwer. Als kleiner Denkanstoß hier mal ein kleiner (C- ) Code-Ausschnitt, mit dem die RGB-Werte einer Palette in die Farbregister geschrieben werden: (Namen der Variablen z.T. symbolisch)

for(i = 0; i < screen->numcregs; i++)
{
SetRGB32(screen->ViewPort, i, screen->cregs[i * 3 + 0],
screen->cregs[i * 3 + 1],
screen->cregs[i * 3 + 2]);
}

Wie man sieht, steht damit die resultierende Reihenfolge der Bytes im Speicher (hier: dem _Array_ der Farbregister) fest. Bestimmt wird die Reihenfolge durch die jeweilige Addition von 0, 1 und 2 zur aktuellen Schreibadresse im Speicher, welche nach einem Schleifen-Durchlauf um 3 Bytes erhöht wird (i * 3!). screen->cregs steht für die Startadresse des zu beschreibenden Speicherbereichs (hier: Adresse des Palettenregisters 0, bei Dir wäre das die Startadresse der Bitmap), i steht hier für die Anzahl bereits gesetzter Palettenregister und gleichzeitig für den Index im Ausgangsdaten-Array sowie das jeweilige Palettenregister. Bei Dir wäre i die Anzahl bereits gelesener Pixel und die aktuelle Position in der zu füllenden Bitmap. Die Ausgangsdaten kommen bei Dir ja von Festplatte/Diskette.

Wenn Du die Additionen in ihrer Abarbeitungs-Reihenfolge umstellst, kannst Du dadurch die resultierende Byte-Reihenfolge im Speicher beliebig anpassen.

Angenommen, die Daten kommen in BGR-Reihenfolge von der Festplatte rein und man benötigt sie aber in der RGB-Reihenfolge, dann stünde im obigen Beispiel die Addition mit 2 an erster Stelle (der B-Wert kommt ja als erstes rein, muß aber im Speicher an "letzter" Stelle des 24Bit-Wertes stehen, nämlich Index + 2 Bytes), die Addition mit 0 an letzter (da der R-Wert als letzter geladen wird, aber an "erster" Stelle des 24Bit-Wertes stehen muß, Index + 0 Bytes). Voilá, die Daten liegen im RGB-Pixelformat im Speicher (der Bitmap). Simpel, oder?

Genauso für das (absolut exotische) GBR-Format. Addition mit 1 an erster Stelle, Addition mit 0 an zweiter Stelle und zuletzt Addition mit 2. Bumms, die Daten liegen in GBR-Reihenfolge im Speicher.

Wenn Du das erledigt hast, einfach die Bitmap in den Screen blitten, fertig.

Noch ein bißchen mehr Geschwindigkeit würdest Du mit Double Buffering beim Laden und Konvertieren erreichen, aber das ist schon ziemlich komplex. Im oben beschriebenen Fall sorgt das Filesystem schon für eine gewisse Pufferung, so daß die Geschwindigkeit beim Laden nicht allzu sehr leidet.

Bedenke aber, daß das _nicht_ mehr so simpel funktioniert, wenn Du die Bilddaten in einer anderen Farbtiefe darstellen willst. In dem Fall solltest Du Dir wirklich Gedanken machen, die guigfx.library o.Ä. zu verwenden. Farbraumkonvertierung ist nicht mehr so trivial

Genauso problematisch ist diese Methode, wenn Du das auf andere Systeme portieren wolltest. PCs zum Beispiel arbeiten mit Little Endianess, bei denen sind die Bytes im Speicher jeweils vertauscht (daher stammt übrigens auch die BGR-Reihenfolge bei Deiner GraKa ). Du müßtest höllisch mit der Bearbeitungsreihenfolge aufpassen.

Da Du aber mit MaxonBasic arbeitest, gehe ich einfach mal davon aus, daß Dir eine Portierung auf z.B. Linux nicht unbedingt vorschwebt

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von DariusBrewka:

Zitat:

---

Hm, Du hast aber schon gelesen, worum es Ralf geht, oder? guigfx und render.library kann er sich da genauso sparen, da CyberGraphX bereits die entsprechende Konvertierung vornimmt, wenn nötig. Da das aber
...

---

Natürlich habe ich dass, nur macht es sich IMO zu viele gedanken um Speed, wozu?.

---

Zitat:

---

Ralf will ein speziellen ImageViewer programmieren, welcher übergrosse Images anzeigen kann unter Umgehung der Datatypes. Es wird Ralf nicht einfach gelingen dieses auf mehr als einige Formate auszudehnen, AFAIK geht's ihm um BMPs, welche im BGR Format vorliegen.

---

Zitat:

---

Sollte Ralf darauf Wert legen, diese Images auch auf Fremden Screens darzustellen, bleibt ihm nichts anderes übrig, sich um die ganzen Konvertierungen&Co zu kümmern.

---

Zitat:

---

Will er einen eigenen Screen, ist das Alles viel einfacher, er kann einen CGX Screen in dem gewünschen Format anfordern und über die CGX Funktionen die Adresse des Bildschirmspeichers besorgen und direkt das Bild dahin entpacken ganz ohne Konvertierungen.

---

Zitat:

---

Ich habe die gleichen Probleme auch vor kurzem gehabt und habe für mich die einzig vorstellbare Lösung gefunden. Speed steht an zweiter stelle, die Einfachheit sollte vorrang haben, erst wenn Alles so geht wie es soll, kann man sich über ersteres gedanken machen.

---

*hüstel* Genau an der Stelle ist Ralf doch jetzt

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:

Ich denke, dein Problem ist Basic. Z.B. ist PicShow in der Lage, ein Bild der Größe 1024*768*24 in Echtzeit mit einem anderen der gleichen Größe zu mischen und mit WritePixelArray auf die Grafikkarte zu übertragen, die in 16bitPC läuft (also mit 24bit RGB ->16bit BGR Konvertierung). Nach deiner Rechnung müßten das 1,5*50, also 75 MB/Sekunde sein.

Da dein Flaschenhals offenbar die Programmiersprache ist, mußt du wohl für alle rechenintensiven Prozesse eine fertige Funktion finden.

---

Zitat:

---

Ich würde zunächst vorschlagen, anstatt einen 24bit RGB-Puffer für WritePixelArray zu benutzen, den du manuell füllen mußt, lieber eine Bitmap im BGR-Format zu nehmen. Diese kannst du mit LockBitMapTags sperren, um einen Pointer auf die Rohdaten zu bekommen und dann mit den BGR-Daten füllen, ohne Konvertierung. LockBitMapTags ist allerdings nicht ganz ungefährlich. Das kann schnell zu Deadlocks führen, je nachdem wie lange man die Bitmap sperrt und was man währenddessen macht.

---

Zitat:

---

Eine andere Möglichkeit wäre, die BMP-Datei komplett nach RGB zu konvertieren und die Roh-RGB-Daten in eine temporäre Datei zu schreiben. Von dort könntest du sie dann ohne Konvertierung für einen Anzeiger laden.

---

Die Konvertierung in RGB läuft schon bei mir beim Laden und das geht ja auch rech schnell. So mach ich das ja auch wenn ich die Datei nicht ganz laden kann, dann werden halt nur Teile geladen und gleich konvertiert in RGB.
Aber der Grund des ganzen:
Wieso alles mehrfach konvertieren wenn es nicht notwenig ist. Es ist da egal was für eine Programmiersprache. Es kostet unnötig Rechenzeit. Oder?

Zitat:

---

Die beste Möglichkeit ist natürlich immernoch, das Programm komplett in C zu schreiben.

---

Zitat:

---

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

---

Achja, ich programmiere das ganze nur aus Fun! Das heißt, es soll mir Spaß machen und macht mir Spaß. Wenn es später vielleicht 1,2 Leute benutzen, ok. Aber in erster Linie ist das ganze für mich halt.

Und genauer hier gerade bei diesem Punkt hier (RGB-BGR) wollte ich halt hier im Forum genauer wissen wie man hier am besten vorgeht wenn man denn maximalen Speed rausholen möchte und die Konvertierungen sparen möchte, die laufend gemacht werden müssen.
Und in der aktuellen Lösung entfällt eh der Bärenanteil der Arbeit auf die CGX-Routinen.

Und: Ich möchte auch was dazu lernen in Sachen CGX, was doch nicht nur mit C funktioniert, sondern auch mit anderen Programmiersprachen.

[ Dieser Beitrag wurde von Ralf27 am 22.04.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:

Ich denke, dein Problem ist Basic. Z.B. ist PicShow in der Lage, ein Bild der Größe 1024*768*24 in Echtzeit mit einem anderen der gleichen Größe zu mischen und mit WritePixelArray auf die Grafikkarte zu übertragen, die in 16bitPC läuft (also mit 24bit RGB ->16bit BGR Konvertierung). Nach deiner Rechnung müßten das 1,5*50, also 75 MB/Sekunde sein.

---

Hmmm, ich komme hier auf ein reines Speichervolumen von insgesamt 6291456 Bytes pro fertigem Bild ((2 x 24Bit + 16Bit)*Pixelzahl, ohne Konvertierungsschritte). Also gut 6MB. Mal 50 wären das ca. 300 MB/sec. reines Transfervolumen (im Speicher hin und her + vom Speicher über den Bus zur GraKa, immer noch ohne Konvertierungsschritte). Meinst Du nicht, daß das ein bißchen arg hoch gegriffen ist selbst für einen Amiga mit CSPPC? Noch dazu, wo das RTG-System nicht PPC-nativ ist? Amithlon, AOne und Peg mögen das schaffen (dank nativer RTG-Systeme bzw. enorm schneller 68K-Emu bei Amithlon und dessen Vorteil der ggf. vorhandenen Busmaster-Fähigkeit der verwendeten GraKa), aber selbst das bezweifle ich ein wenig.

Ich traue dem BlizzardPPC-System ca. 40MB/sec. über den Mini-PCI zu, wenn der 060 im Einsatz ist, allerdings habe ich nie verlässliche Aussagen dazu gehört.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

Zitat:

---

Original von thomas:

Ich denke, dein Problem ist Basic. Z.B. ist PicShow in der Lage, ein Bild der Größe 1024*768*24 in Echtzeit mit einem anderen der gleichen Größe zu mischen und mit WritePixelArray auf die Grafikkarte zu übertragen, die in 16bitPC läuft (also mit 24bit RGB ->16bit BGR Konvertierung). Nach deiner Rechnung müßten das 1,5*50, also 75 MB/Sekunde sein.

---

Hmmm, ich komme hier auf ein reines Speichervolumen von insgesamt 6291456 Bytes pro fertigem Bild ((2 x 24Bit + 16Bit)*Pixelzahl, ohne Konvertierungsschritte). Also gut 6MB. Mal 50 wären das ca. 300 MB/sec. reines Transfervolumen (im Speicher hin und her + vom Speicher über den Bus zur GraKa, immer noch ohne Konvertierungsschritte). Meinst Du nicht, daß das ein bißchen arg hoch gegriffen ist selbst für einen Amiga mit CSPPC? Noch dazu, wo das RTG-System nicht PPC-nativ ist? Amithlon, AOne und Peg mögen das schaffen (dank nativer RTG-Systeme bzw. enorm schneller 68K-Emu bei Amithlon und dessen Vorteil der ggf. vorhandenen Busmaster-Fähigkeit der verwendeten GraKa), aber selbst das bezweifle ich ein wenig.

Ich traue dem BlizzardPPC-System ca. 40MB/sec. über den Mini-PCI zu, wenn der 060 im Einsatz ist, allerdings habe ich nie verlässliche Aussagen dazu gehört.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

---

Weiter oben dazu hier im Thread hab ich einige Daten vom http://www.amigaspeed.de.vu gefunden und diese einmal umgerechnet:
24Bit= ca. 8MB pro Sek (zur Zeit mit meinem System, noch aber mit einem kleinen Denkfehler (24Bit=ARGB=32Bit dann ca. 10MB pro Sek) )
16Bit= ca. 35MB pro Sek(mit 16Bit, noch nicht getestet)

Ich denke auch das 40MB das maximale wäre, bzw. ohne Konvertierung. Vielleicht auch etwas mehr. Und genau das interesiert mich, das möchte ich herrausfinden.



PS: PicShow hab ich auch hier. Also so schnell war es bei mir auch nicht, das es in Echtzeit in 1024*768 sowas bringt. Aber ich hab auch kein HighEnd-Amiga. PicShow gefällt mir aber dennoch. . Aber wenn man sich mal die Zahlen ansieht, es werden schon extreme Datenmengen transportiert (für einen Amiga)

Wie schnell kann der 060er Daten transferieren? 45MB pro Sek bei der 603e?

[ Dieser Beitrag wurde von Ralf27 am 22.04.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Wie schnell kann der 060er Daten transferieren? 45MB pro Sek bei der 603e?

[ Dieser Beitrag wurde von Ralf27 am 22.04.2005 editiert. ]

---

Wollt grad was dazu schreiben

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

P.S.: Deine Überlegungen zu 24Bit stimmen schon. CGFX/P96 unterstützen in den 68K-Versionen keinen Alpha-Channel, daher werden die Alpha-Channel-Bytes beim Transfer von 24Bit-Pixeln quasi übersprungen (beim Transfer wird implizit ein Byte hinzugefügt um ein komplettes Langwort übetragen zu können). Mit ein Grund dafür, weshalb WritePixelArray() bei 24Bit ziemlich langsam ist. Bei 15/16Bit ists kein Thema, weil da der ggf. vorhandene "Alpha-Channel" (ist eigentlich mehr ne Art Maske, weniger ein echter Alpha-Channel) nur ein Bit in zwei Bytes darstellt. Man beläßt es auf NULL und überträgt einfach die beiden Bytes, implizite Konvertierung in ein Langwort ist da nicht notwendig bzw. kann man zwei Pixel auf einmal in einem Langwort übertragen. Daher auch der beachtliche Geschwindigkeitszuwachs.


[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Wenn ich endlich mal Zeit habe, dann werde ich die Sache mit dem AllocBitmap machen und genau so eine Bitmap aufmachen wie im aktuellen Screen.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:

Zitat:

---

Wenn ich endlich mal Zeit habe, dann werde ich die Sache mit dem AllocBitmap machen und genau so eine Bitmap aufmachen wie im aktuellen Screen.

---

Das war nicht das, was ich meinte. Damit mußt du ja doch die Daten selbst konvertieren, was in Basic das langsame ist.

Du sollst vielmehr eine Bitmap anlegen, die das gleiche Format hat wie die BMP-Datei. Dann kannst du die Daten ohne sie zu konvertieren direkt in den Speicher der Bitmap schreiben. Die Bitmap kannst du dann mit BltBitMap() in den Screen schreiben. Dabei übernimmt CGX die komplette Konvertierung. Das dürfte das schnellste sein, was man mit Basic erreichen kann.

Gruß Thomas

---

Naja, im Endeffekt ist es das, was wir ihm die ganze Zeit schon sagten

Allerdings hast Du übersehen, daß in seinem speziellen Fall dann _gar keine_ Konvertierung nötig wäre, weil sein Screen ja schon im BGR-Format aufgebaut ist (Permedia2 mag halt kein RGB). Sein Problem war einzig, daß er mit WritePixelArray() arbeitete, welches gern RGB-Reihenfolge für die Ausgangsdaten hätte. Dadurch erreichte er nicht das Maximum an Transfer-Geschwindigkeit. Deswegen habe ich ihm empfohlen, die Konvertierung beim Laden selbst vorzunehmen, weil dann der Transfer _ohne_ Konvertierung durch CGFX abläuft.

Im Grunde ist es für ihn mehr oder weniger nur ein Lernprojekt, da nützt es ihm nicht viel, wenn man ihn ständig darauf hinweist, daß CGFX bereits Konvertierungen erledigt, wenn nötig. Das müßte er inzwischen verstanden haben

Man lernt nicht dadurch, daß man ein Rad benutzt, seine Interna zu verstehen, sondern eher dadurch, daß man selbst eins baut.

Grüße

P.S.: Eine Frage habe ich noch. Warum beißt Du Dich so am BASIC fest? Bei manchen Programmen spielt es keine großartige Rolle, ob sie mit nem C-Compiler oder nem BASIC-Compiler gebaut wurden, das Ergebnis ist im Groben das Gleiche und die BASIC-Variante nicht unbedingt langsamer. Als kleines Beispiel für ein "Husarenstück" eines BASIC-Programmierers empfehle ich immer einen Blick auf "AsteroidsTR" von Thilo Köhler. Reines BASIC

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

So, heute Abend werd ich dann die Quellcode springen lassen.

Alerdings wenn ich das richtig sehe, dann muß dann auch beim Blitten, wenn ich die Daten im BGR-Format im Bitmap haben, auch Konvertiert werden und zwar von BGR auf ABGR. Ok, das macht die Routine. Aber mal sehn was da rauskommt.

Achja, wieso ich in BASIC so vernarrt bin:
Weil es mir Spaß macht. Hab bis jetzt ein Programm in C geschrieben und bin nie über das "Hello World" herrausgekommen. Hat mir leider auch nicht richtig Spaß gemacht.

Der jetzige BMP-Reader in Basic läuft schon recht schnell (v0.6) und ich will halt sehn was da noch drin steckt.

Achja, die Konvertierung von BGR auf RGB läuft auch in Basic recht schnell. Also so langsam ist Basic nun auch wieder nicht.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Achja, wieso ich in BASIC so vernarrt bin:

---

Upps, mit dem P.S.: meinte ich eigentlich mehr Thomas, weil er das Tempo-Problem nur aufs Basic zurückführen wollte

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Achso.

Ich bin es halt schon gewöhnt das sowas kommt wie "was, du benutzt noch Basic? wieso denn nicht C?" .



Achja, mal was anderes:
Ich hab ja mal einfach zwei "neue" Darstellungsmöglichkeiten eingebaut:
* eHAM8
* uHAM8

Hat diese schonmal jemand getestet? Ich würde dazu gerne mal eure Meinung wissen.
PS: Mir ist klar das es in Zeiten von Grafikkarten sowas sinnlos ist, aber egal, es hat mir Spaß gemacht.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Ich hab es eben mit dem AllocBitmap versucht, aber leider versteh ich das ganze nicht so richtig. Mein Englischproblem...

Ich würde da gerne mal ein Beispiel sehn, bzw. wie man die Daten in die Bitmap bekommt und wie man es kopiert, bzw. denn ganzen Aufbau. In der Theorie hab ich es ja verstanden, aber in der Praxis macht mein System "dicht".

---

Wenn Du noch bis zum Wochenende Zeit hast (und Thomas mir nicht zuvorkommt, was aber recht wahrscheinlich ist )...

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Ich bin es halt schon gewöhnt das sowas kommt wie "was, du benutzt noch Basic? wieso denn nicht C?" .

---

[ - Answer - Quote - Direct link - ]