|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Transverspeed PPC603e -> BVision | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 3 4 | [ - Beitrag schreiben - ] |
|
19.04.2005, 17:38 Uhr Ralf27 Posts: 2779 Nutzer |
Ich hab eben mein kleines Programm umgeschrieben auf only CybergraphX und hab mal denn Speed getestet. Für ein 24Bit, 3,6MB großes Bild braucht mein Programm für denn Transver zur Grafikkarte (1600*1200*24) ca. 1 Sekunde. Somit erreiche ich in dieser Auflösung ca. 3,6MB pro Sekunde. Wie schnell ist eigentlich die BVision? Wie schnell kann ich Daten auf die Grafikkarte schaufeln? Es müßte doch eigentlich schneller gehn als 3,6MB pro sek, oder? PS: Need more Speed.  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 18:28 Uhr whose Posts: 2156 Nutzer |
Zitat: Dann beschreib doch mal, auf welche Weise Du die Bilddaten zur GraKa übertragen läßt, davon hängt die Geschwindigkeit nämlich unmittelbar ab. Im übrigen solltest Du ganz scharf darauf achten, ob Du die Bilddaten nicht zufällig im Chip RAM liegen hast. Wenn doch, brauchst Du Dich über die "Geschwindigkeit" nicht zu wundern Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 18:59 Uhr MaikG Posts: 5172 Nutzer |
PCI geschwindigkeit? Muss am Sourcecode liegen. Beim 68060 REM $NOOVERFLOW Die Funktion verlangsamt das Programm auf 060 extrem. [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 20:44 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Die Daten liegen im Fastram. Wenn sie im Chip wären und diesen Speed erreichen würde, dann wäre es doch eigentlich unglaublich, oder? Ich jag die Daten mit einem einzigen Befehl komplett in die Grafikkarte: Bis 8Bit mit WriteLUTPixelArray und bei 24Bit mit WritePixelArray. Somit läuft der gesamte Transver ab. Und genau diese Befehle brauchen so lange. Wie kann man das beschleunigen? Andere Befehle? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 20:49 Uhr Holger Posts: 8116 Nutzer |
Zitat:Bei mir sind 1600x1200x3 5760000 bytes, also 5,5 MB, die transferiert werden müssen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 19.04.2005 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 20:57 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Unwahrscheinlich das es am Programm liegt, denn ich rufe gerade mal einen Befehl auf aus dem System (cybergraphX) und dieser braucht so lange. Aber die ganzen Compileroptionen setze ich schon, das macht schon recht viel aus. Das hab ich ja auch schon alles ausgetestet. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 20:58 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Ja, aber das Bild ist kleiner das da rein verschoben wird. Und dieses hat ca. 3,6MB Rohdaten (24Bit RGB) -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 22:00 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ist das in jedem Fall RGB oder auch BGR etc, ja nach Bedarf? Wenn ich mich recht entsinne, erlaubt die CGX-Funktion verschiedene Formate, die dann in das tatsächliche Screen-Format konvertiert werden. Das tatsächliche Pixelformat vorher zu ermitteln, und die Bilddaten gleich in diesem Format vorzuhalten, könnte durchaus die Performance verbessern. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 22:14 Uhr whose Posts: 2156 Nutzer |
Zitat: Das ist auch bei P96 so, weil sonst z.B. die Workbench auf nem 24Bit-Screen nicht machbar wäre. Allerdings hätt ich auch darauf kommen können, daß das Format der zu übertragenden Daten dem Screen "nicht paßt". Das könnte des Rätsels Lösung sein, diesen Zusammenhang übersieht man leicht. Naja, mal schauen was Ralf uns jetzt dazu sagt  Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 22:24 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Ich hab immer was zu tippen! Also, das mit dem Format ist so eine Sache. Es wäre wohl wirklich am besten wenn beides zusammenpast: Screen und Daten. Hm, mal sehn wie ich das mach. Muß mich mal später mal durch die AutoDocs stöbern und mal sehn wie ich das mach. Eigentlich würde dieser Speed auch reichen, aber ich will mehr!  Wie hoch ist aber denn nun eigentlich der theoretische MaxSpeed von der 603e über den miniPCI-Port in die Grafikkarte?  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 23:01 Uhr whose Posts: 2156 Nutzer |
Zitat: Das hab ich mir irgendwie schon gedacht Zitat: 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?  Zitat: GetCyberMapAttr() dürfte das Gesuchte sein Zitat: Gute Frage, nächste Frage. Kannst ja mal mit direktem Zugriff aufs Video RAM messen (und nur zum Messen direkter Zugriff )Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
19.04.2005, 23:09 Uhr Ralf27 Posts: 2779 Nutzer |
So, ich hab eben mal nachgesehn. Also, die WB ist wirklich ein BGR-Screen, aber auch der Screen der mein Compiler aufmacht. Das bedeutet, das ich ein RGB-Screen verlangen muß, da ich ja leider nicht die Daten im BGR-Format an WritePixelArray übergeben kann. Hm, jetzt vermute ich mal das nicht alle Grafikarten einen RGB-Screen aufbauen können. Da muß ich wohl noch einiges einbauen. Zur Zeit benutze ich ja in Basic einfach denn Screen Befehl, um einen Screen zu öffnen. Ich muß wohl bald die Systemroutinen benutzen. Mal sehn ob ich auch testweise die WB auf ein RGB-Screen legen kann. Was für ein Vorteil hat denn ein BGR-Screen gegenüber einem RGB-Screen? Wieso gibt es denn 2 Varianten und nicht nur eine? Wollte da jemand die Programmierer ärgern? Oder wollte da Microsoft einen neuen Standard definieren(die machen ja die Hardware über ihre Software verrückt)? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 00:12 Uhr Ralf27 Posts: 2779 Nutzer |
Nicht so einfach mit dem BGR-Screen aufmachen. Hab es eben mit dem CModeRequestTagList versucht, aber leider lief das auch nicht richtig. Ich hab als einzige TAG-Übergabe angegeben das ich nur BGR-Screens will, die Auswahl bringt mir nur 8Bit-Screens... ? Gehe ich recht in der Annahme, das ein RGB-Screen nur eine andere ID hat als ein BGR-Screen? Was für eine ID hat 1024*768*24 RGB (BGR) auf der BVision? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 02:48 Uhr whose Posts: 2156 Nutzer |
Zitat: Erst ists BGR, dann gehts nicht? Naja, lange Rede, kurzer Sinn: Schau Dir mal in den CGFX-Autodocs die Abteilung über das modifizierte AllocBitMap() an, damit kannst Du einer Bitmap bereits beim Anlegen das benötigte Format mitgeben und die später relativ einfach z.B. via Blit...-Funktionen in eine Screen-Bitmap "blitten" (klingt komisch, wenn man bedenkt, daß die Daten im FastRAM liegen können ). AllocBitmap() ist wie gesagt durch CGFX (P96) modifiziert, um auch Bitmaps eines anderen Formats als Planar einigermaßen systemkonform anlegen zu können. Das entsprechende Flag hört auf den Namen BMB_SPECIALFMTDu kannst diese "selbstgebaute" Bitmap allerdings nicht zum Öffnen eines Screens verwenden, mußt schon noch die Daten selbst von Deiner selbstgebastelten Bitmap in den gewünschten Screen übertragen, z.B. über die Blit...-Funktionen. 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. Mit der Methode kannst Du alle möglichen Formate verarzten (sofern die von CGFX/P96 unterstützt werden). Hast aber sicher gemerkt, daß Du da um eine Konvertierung so oder so nicht herumkommst, aber auf diese Weise verlegst Du die Konvertierung geschickt auf den Ladevorgang, wo es nicht so auffällt . Zusätzlich umgehst Du damit das (in CGFX) lahme WritePixel() (bevor wer weint: P96 hat auch so seine "Flaschenhälse" in der 68K-Version).Im Zweifelsfall bleibt Dir immer noch der harte Weg des direkten Zugriffs offen, aber vor dem Weg warne ich Dich nicht ohne Grund. Müßtest nämlich _alle_ möglichen Bitmap-Formate berücksichtigen  Grüße P.S.: Übrigens: Halt Dich nicht so sehr an den "speziellen" Formaten und schon gar nicht an bestimmten Screenmode-IDs fest, das geht ins Auge! Nimms einfach hin, daß es verschiedene Formate gibt und leg entsprechend aufgebaute Bitmaps mit den dafür vorgesehenen Systemfunktionen an. Dann läufts nämlich auch auf anderen GraKas als der BVisionPPC Kleiner Tip noch zum Schluß: Schau mir mal die BlitzBasic2-Includes von Thilo Köhler an, da findet man ne Menge Information, wie man mit GraKa-Bitmaps >8Bit und Systemfunktionen arbeitet, und das sogar ziemlich fix.-- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 09:08 Uhr gni Posts: 1106 Nutzer |
Zitat:Du hättest das f groß schreiben sollen. So fällt es kaum auf ;-) [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 09:22 Uhr Ralf27 Posts: 2779 Nutzer |
Ja, ist etwas verwirrend. Also die Daten liegen im BGR-Format vor. Die CybergraphX-Funktion braucht die Daten im RGB-Format (ok, gibt es die Möglichkeit mit RGBA, ARGB, etc.), also muß ich diese Wandeln. Der Screen war bis jetzt immer BGR, aber leider würde dann wieder(!) die Funktion von CybergraphX die Daten wandeln, also müßte ein RGB-Screen her. Ich hab mich da oben auch schon etwas verschrieben mit RGB<->BGR. Achja, die Transfer-Sache: Ich dachte auch erst, da würde eventuell Dreck auf dem Monitor liegen, da der eine Buchstabe so fett ist Das sind die lieben kleinen Fehler die einem nie auffallen das sie falsch sind wie z.b. der berühmte Standard. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 09:40 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Hm, wenn das wirklich funktioniert (muß mich erst mal wieder durcharbeiten, aber jetzt geht wieder die Firma vor), dann muß ich gar nicht konvertieren und hab so gleich nochmal viel mehr Speed!  Die Rohdaten liegen im BGR-Format vor und wenn ich so die Daten in denn Speicher bekomme und ich auch so "blitten" kann, dann geht es wirklich sehr viel schneller. Bin schon gespannt, mich juckt es sogar schon in den Fingern das ganze auszutesten. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 10:15 Uhr whose Posts: 2156 Nutzer |
Zitat: Allerdings nur für den Fall, daß die GraKa die Bitmap im BGR-Format anlegt. Das gilt "leider" nicht für alle GraKas. Denk auch an die armen "Schweine", die keine B/CVisionPPC ihr eigen nennen können Probiers aber erstmal aus. Später kannst Du ja immer noch die Konvertierung ins jeweils passende Bitmap-Format in Deine Laderoutinen einbauen. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 10:29 Uhr MaikG Posts: 5172 Nutzer |
>Zur Zeit benutze ich ja in Basic einfach denn Screen >Befehl, um einen Screen zu öffnen. Ich muß wohl >bald die Systemroutinen benutzen. Solltest du unbedingt, dir scheint nicht bekannt zu sein das MB für Screen und Windows Chip-Speicher benutzt? [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 10:43 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Ne, das ist mir wirklich nicht bekannt. Auch wenn der Screen auf der Grafikkarte aufgemacht wird? Darauf habe ich nie geachtet. Mit dem Screen-Befehl ist es halt sehr einfach einen beliebigen Screen aufzumachen. Aber irgendwie... wie bekommt er bei 1600*1200*24 über 5MB Chipram? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 12:13 Uhr whose Posts: 2156 Nutzer |
Zitat: Eben. Deswegen: Keine Panik! MaxonBasic nutzt dazu (wie es sich gehört ) OS-Funktionen, die durch das RTG-System schon "zurechtgepatcht" sind damit nix im ChipRAM landet, wenn nicht zwingend notwendig.Ich weiß allerdings nicht, ob Du an die RastPort-Struktur der MB-internen Screens/Windows herankommst. Die brauchst Du, wenn Du von Deiner "selbstgebauten" in die Screen-/Window-Bitmap "blitten" willst. Aber selbst, wenn das nicht gehen sollte: Dir bleiben immer noch die OS-Funktionen Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 12:27 Uhr Ralf27 Posts: 2779 Nutzer |
[quote] Original von whose: Zitat: Leider hab ich diesen Flag nicht in meiner Include gefunden und hab eben mal in der C-Include nachgesehn und ihn dort gefunden. Ist der Wert 7? Denn müßte ich dann auch in meinen MB-Includes einfügen. PS: Blöder Tag heute. Ich hab hier nur Minutenweise Arbeit in der Firma und heute Abend geht es wieder rund mit einem Auftrag. Zsss. Arbeiten, wenn Arbeit da ist und Freizeit wenn keine da ist. Aber ich denke mir mal, das das bald bei vielen so gehen wird. Allerdings bekommen die Arbeiter immer mehr Lasten aufgedrückt und die reichen Leute werden immer reicher... grummel...  [ Dieser Beitrag wurde von Ralf27 am 20.04.2005 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 12:37 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Da ich immer denn Screen-Befehl benutze und auch eigentlich immer denn Windows Befehl, benutze ich auch die Windows-Funktion, um an die Strukturen zu kommen wie z.b. rastport&=window(8) oder win&=window(7) Wenn dies nicht möglich gewesen wäre, dann hätte ich ja viele Betriebssystemroutinen nicht nutzen können. Allerdings finde ich es sehr interesant zu sehn das viele MB-Demos über die Systemroutinen gehn. Allerdings sehen dann die MB-Demos aus wie C-Quellcode. Teilweise versteh ich dann nur Bahnhof, denn dann sieht für mich wirklich C und MB gleich aus. Man sieht da schon das die Entwickler da aus dem C-Bereich kommen und halt logischerweise so in MB proggen wie sie es halt auch im C machen würden. Aber ich möchte halt das ganze in MB durchziehn und eigentlich müßte das auch soweit gehn und ich dürfte auch an die maximale Geschwindigkeit der Grafikkarte kommen, da ja die ganze "Rechenlast" auf den Systemroutinen liegt. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 14:03 Uhr Ralf27 Posts: 2779 Nutzer |
Hab mich eben mal etwas erkundigt: Laut http://www.amigaspeed.de.vu erreichte ich maximal ca. 6,2MB pro Sekunde bei 24Bit. (bei 210MHz, ich hab 240MHz) Das hat mich sehr überrascht, denn ich erreiche diesen Wert zur Zeit auch und das mit der Konvertierung! Bei der letzten Messung hab ich bei mir einen kleinen Fehler gemacht. Es lief einfach zuviel im Hintergrund, bzw. irgendwas hat zu diesem Zeitpunkt Rechenleistung "gefressen", denn der jetzige Test brachte 3,6MB pro 0,41 Sek= ca. 8,8MB pro Sekunde bei 1600*1200*24. Laut amigaspeed ist der 16Bit-Screen nochmal 4 mal so schnell, wobei wir dann bei 35MB pro Sek wären. Ich muß echt tippen das es wirklich langsam schnell wird. (bevor hier jetzt einige anfangen zu tippen: für Amiga-Verhältnisse) Und dann sollte man noch tippen das da noch die Konvertierung in Echtzeit läuft, die man ja auch vorher auch noch machen kann. Ich sehe da noch SpeedUp-Möglichkeiten. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 19:10 Uhr MaikG Posts: 5172 Nutzer |
>Ne, das ist mir wirklich nicht bekannt. Auch wenn der >Screen auf der Grafikkarte aufgemacht wird? Das hab ich nicht probiert. Auf meiner Workbench sind immer 2 MB Chip frei, wenn dann 200kb fehlen wenn MB ein Fenster auf macht, ist klar was sache ist. Das Fenster war auf der Workbench - 16 Bit Grafikkarten Schirm. Seitdem nehme ich die Fenster vom System, sind viel schneller. >Darauf habe ich nie geachtet. Mit dem Screen-Befehl ist >es halt sehr einfach einen beliebigen Screen aufzumachen. Ich denke das schaffst du auch mit Betriebssystem Routinen. [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 20:22 Uhr Holger Posts: 8116 Nutzer |
Zitat: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. 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. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 20:53 Uhr Holger Posts: 8116 Nutzer |
Zitat: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. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 22:24 Uhr Ralf27 Posts: 2779 Nutzer |
So, erstmal Stück für Stück: BMB_SPECIALFMT: Leider hab ich diesen Flag nicht in meiner Include gefunden und hab eben mal in der C-Include nachgesehn und ihn dort gefunden. Ist der Wert 7? Denn müßte ich dann auch in meinen MB-Includes einfügen. Rohdaten BGR: Ich hab die Daten ins RGB-Format gewandelt, weil es so die WritePixelArray-Funktion verlangt. Wenn ich aber die BGR-Daten so in eine mit AllocBitmap generierte Map (mit BGR-Format) ablege, kann ich also die BGR-Daten direkt in ein BGR-Screeen mit ClipBlit(?) kopieren? Langsam bekomm ich en Knoten im Hirn. Andere Frage: Ich hab versucht mit CModeRequestTagList eine Auswahl mit entsprechenden Screens (Farbtiefe vorgegeben=24, RGB-Farbformat=9) zur Auswahl zur stellen, aber leider bringt er mir dann nur 8Bit-Screens? PS: Mir ist klar das man ASL-Requester nehmen sollte. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.04.2005, 22:26 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Ist mir noch nie aufgefallen. Werde mir das später einmal genauer ansehn. Aber ich kann mir kaum vorstellen das MB die Fenster anderst auf macht, bzw. für was er dann z.b. 200kb reserviert. Für die Option 16(Refresh)? Wäre möglich... Muß ich mir später mal alles ansehn, wenn ich Zeit hab. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
21.04.2005, 01:31 Uhr whose Posts: 2156 Nutzer |
Zitat: Das müßte Bit 7 im Flag-Byte sein, also Dezimal 128. Schau ich im Zweifel aber gern nach. Zitat: Ja, das habe ich mir schon gedacht Zitat: Alles halb so wild Ja, wenn Du die Daten bereits im passenden Format (also passender Byte-Reihenfolge, Endianess beachten!) aus der Datei bekommst, kannst Du die direkt in Deine eigene Bitmap reinschreiben und diese dann auf die GraKa rüberblitten.Zitat: Das hat mit der Art des verwendeten Requesters wenig zu tun. Das liegt schlicht daran, daß der Permedia2-Grafikchip, der auf der C-/BVisionPPC eingesetzt wird, in den Modi >8Bit nur BGR-Reihenfolge unterstützt (soweit ich weiß. Wenns anders ist, bitte korrigieren). Nur bei den 8Bit-Modi bietet der Chip RGB-Format für die _Paletten-Einträge_ an. Daher siehst Du eben auch nur die 8Bit-Modi im Requester. Probiers doch mal umgekehrt, dann müßten die 8Bit-Modi verschwinden Du solltest allerdings in Deinem Programm darauf verzichten, bestimmte Pixelformate bei der Screen-Auswahl vorauszusetzen. Nicht jeder hat ne GraKa, die BGR-Pixelformat bietet und diejenigen bleiben dann außen vor. Schreibs lieber gleich so, daß es die Bilddaten gleich in das von der GraKa benötigte Pixelformat konvertiert, dann läufts überall. Ist zwar mehr Arbeit, bringt aber auch mehr "Kunden" Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 21.04.2005 editiert. ] [ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 3 4 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Transverspeed PPC603e -> BVision | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|