|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Amiga, AmigaOS 4 > P96 oder Cgfx3 ? | [ - Search - New posts - Register - Login - ] |
| 1 -2- | [ - Post reply - ] |
|
2005-04-21, 03:18 h whose Posts: 2156 User |
Zitat: Soweit ich weiß, besitzt die CV64 keine 3D-Hardware, wäre daher also der CV64/3D bei 3D automatisch unterlegen. Allerdings wurde bei der CV64 der Zorro3-Bus besser implementiert, daher ist die CV64 in 2D meist etwas schneller als die 3D-Variante. Zum Thema ReadPixel(): Alte Software, die von ReadPixel() den Rückgabewert in 8Bit erwartet, läuft mit _allen_ RTG-Systemen auf einem Screen >8Bit nicht ordentlich. Ebenso Software, die von Planar-Grafik ausgeht, ohne diese ausdrücklich anzufordern. Alles andere (systemkonforme Entwicklung des jeweiligen Programms vorausgesetzt) läuft unter P96 genauso gut oder schlecht wie unter CGFX. Zumindest habe ich hier auf allen Systemen (CGFX/P96 gemischt) die gleiche Software-Ausstattung, und z.B. PersonalPaint ist unter CGFX genauso schwierig zu handhaben wie unter P96. Ansonsten habe ich nie einen Unterschied bemerkt, sogar bei meinen selbstgebauten Spielen nicht. Würde mich auch wundern, weil das grundlegende Konzept jeweils stark ähnlich ist. Es ist z.B. kein Problem, ein Programm mit direktem VRAM-Zugriff auf beiden Systemen laufen zu lassen. Wenns mit CGFX3 geht, gehts auch mit P96. Umgekehrt ist schon schwieriger, geht aber auch, sofern man keine "Spezialitäten" des jeweiligen RTG-Systems benutzt. Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2005-04-21, 11:17 h NoImag Posts: 1050 User |
Zitat: Im Prinzip, ja. Ich habe aber mal gelesen, dass es mit der 3D-Beschleunigung beim Virge nicht so toll sein soll. Es wäre daher möglich, dass man von der 3D-Unterstützung bei der CV64/3D nicht viel hat. Damit kenne ich mich aber nicht so aus. Zitat: Schon richtig, dass dies auch auf CGFX nicht korrekt läuft. Bei P96 ist aber aufgrund der erweiterten Interpretation der Autodocs ein Guru möglich. Mit CGFX bleibt einem dies erspart. Zitat: Da gibt es einen Unterschied: Seit AmigaOS 3.0 darf kein Programm mehr davon ausgehen, dass die Daten planar vorliegen. Davon, dass einige Befehle in Zukunft nicht mehr funktionieren (wie ReadPixel unter P96 >8Bit), ist aber in den Anweisungen von Commodore nirgendwo die Rede. [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 11:35 h Bluebird Posts: 3260 User |
der s3 virge war wohl doch einer der ersten 3d chips ueberhaupt und man darf wirklich keine wunder erwarten es ist zum teil nichteinmal schneller durch den chip sieht aber meistens deutlich besser aus als rein im software renderer ... mfg Bluebird [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 11:42 h whose Posts: 2156 User |
Zitat: Ich habe eine CV64/3D. Wenn der VirgeDX genutzt wird, geht das schon einigermaßen ab. Gut zu sehen bei Descent, welches dadurch sogar auf nem 030/50 radebrechte spielbar wird. Zitat:Zitat: Kannst Du das mal näher erläutern? Ich habe heut Nacht mal ein wenig mit ReadPixel() gespielt und kann da keine Anzeichen für eine "erweiterte" Interpretation entdecken. Geschweige denn, daß ich nen Guru präsentiert bekam. Wie es sich (laut AutoDocs) gehört, gab P96 für z.B. nen 16Bit-Screen -1 zurück statt einem Paletteneintrag. Zitat:Zitat: Wie gesagt, das kann ich nicht nachvollziehen. ReadPixel() verhält sich hier unter P96 exakt so wie unter CGFX oder AGA, es gibt -1 zurück , wenn ein Screen >8Bit ohne Palette vorliegt und das wars. So sollte es ja auch sein. Wenn die alte Software damit aber nicht klarkommt, ist das weniger die Schuld des RTG-Systems sondern die des Software-Entwicklers. Der hat dann schlicht und ergreifend gepennt und/oder die Autodocs nur halb gelesen. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2005-04-21, 13:35 h Tobibrocki Posts: 152 User |
Zitat: Geht da jeder Scandoubler, also ich rede jetzt von dem den Vesalia anbietet !? Verbinden mit normalen VGA kabeln, oder wird da ein spezielles benötigt ? Wie soll man das einstellen mit AGA und CV64 screens ? Wie soll ich die Kabel verbinden ? Kann ich dann ganz normale AGA Programme, z.B. PPaint 6.4 oder andere Programme auf dem selben Bildschirm benutzen (oder schaltet die CV64 da hin und her; zwischen AGA und Graka Modi); also ich meine ob AGA Programme die in einem AGA Modi in einem Fenster (nicht screen) auf dem WB screen laufen ebenfalls in einem Fenster auf dem WB scr. eines Graka Modi laufen (oder in einem eigenen screen) ? In sachen Scandoubler hab ich hier noch einen MV1200, aber der ist sicherlich wie der name schon sagt nur mit einem A1200 normal verwendbar !? -- Der perfekte Platz für einen PC ist die Tonne ! [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 14:56 h NoImag Posts: 1050 User |
Zitat: Es geht jeder Scandoubler, es geht sogar ohne Scandoubler mit der original AGA-(oder ECS- oder OCS-)Grafik. Der Scandoubler hat einen Ausgang, über den du normalerweise den Scandoubler mit dem Monitor verbindest. Diesen Ausgang verbindest du statt mit dem Monitor mit dem Eingang an der Slotblende der CV64 (Die CV64 hat in der Slotblende zwei Stecker, eins ist der Ausgang zum Monitor, eins der Eingang für die Amiga-Grafik/Scandoubler). Was das Kabel betrifft: Bei meiner CV64 war ein passendes Kabel im Lieferumfang. Was das für ein Kabel ist, weiß ich aus dem Kopf nicht. Ich muss erst gucken, ob dazu etwas in der Dokumentation zur CV64 steht. Zitat: Mit AGA- und CV64-Screens brauchst du nichts einstellen. Wenn du bei einem Programm einen AGA-Screen auswählst, dann siehst du auf dem Bildschirm den AGA-Screen, wenn du einen CV64-Screen auswählst, dann siehst du den CV64-Screen. Du kannst mit dem Screen-Tiefensymbol oben rechts ganz normal zwischen den Screens blättern, vollkommen unabhängig davon, ob AGA oder CV64, dass heißt, du kannst Programm A auf einem AGA-Screen betreiben und Programm B auf einem CV64-Screen. Wenn du nun mit dem Screen-Tiefensymbol von Programm A nach Programm B umschaltest (oder umgekehrt), dann merkst als Anwender nicht, dass das eine ein AGA- und das andere ein CV64-Screen ist. Du machst dir da völlig unnötige Sorgen. Zitat: Die Modi sind immer Screen-Modi. Fenster-Modi gibt es nicht (gab es noch nie). Als Beispiel: Wenn deine Workbench ein CV64-Screen ist, dann laufen alle Programme, die ihre Fenster auf der Workbench öffnen unter CV64. Wenn deine Workbench ein AGA-Screen ist, dann laufen entsprechend alle Programme, die ihre Fenster auf der Workbench öffnen, unter AGA. Bei systemkonformen Programmen gibt es normalerweise keine Probleme, wenn sie auf einem CV64-Screen laufen, insbesondere, wenn der Screen nur 8Bit tief ist. Wenn du bei einem Programm ein Problem entdeckst, dann solltest du ausprobieren, das Programm auf einem eigenen Screen laufen zu lassen. Wenn die Workbench z.B. 16 Bit ist, probier erst einen eigenen 8Bit-CV64-Screen für das Programm und wenn es dann immer noch Probleme gibt, dann verwende für das Programm einen eigenen AGA-Screen. Zitat: Den MV1200 kenne ich nicht. Wenn das ein externer Scandoubler ist, dann sollte er mit jedem Amiga funktionieren. Wenn das ein Scandoubler für den Video-Steckplatz (wie im A4000) ist, dann brauchst du einen Video-Steckplatz. Wenn das noch etwas anderes ist, dann weiß ich es nicht. Tschüß, [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 15:27 h NoImag Posts: 1050 User |
Zitat: Zitat:Zitat: Die Autodocs sagen, wenn ein Pen nicht angegeben werden kann, dann gibt es -1 als Ergebnis. Von Bildschirmen >8Bit steht in den Autodocs kein Wort. Auch Bildschirme >8Bit haben üblicherweise eine Palette (SetAPen hat bisher immer funktioniert). Trotzdem gibt P96 -1 zurück, selbst dann, wenn der Punkt mit WritePixel oder ähnlichem geschrieben wurde. Ein Programm aus der Ära vor CGFX kann nicht wissen, dass ReadPixel unter >8Bit grundsätzlich nicht funktionieren wird. Wenn der Programmierer sehr vorsichtig war, dann testet er immer auf -1, selbst dann, wenn es eigentlich unnötig sein sollte (ein Guru bleibt einem dann erspart). Das Programm steht aber völlig auf dem Schlauch, weswegen ReadPixel nicht funktioniert. Es kann dem Anwender höchstens sagen: Geht nicht, warum weiß ich nicht! Das Programm kann auch nicht verhindern, dass der Anwender einen Screen >8Bit auswählt. Das dazu notwendige Wissen gab es vor CGFX noch nicht! Versteh mich nicht falsch: Was P96 macht, ist nicht im Widerspruch zu den Autodocs. Es garantiert aber, dass Software aus der Ära vor CGFX fehlschlägt, ohne dass der Programmierer etwas falsch gemacht hat. Darum "erweiterte Interpretation". Wenn der Programmierer nicht vorsichtig war (also nicht immer auf -1 testet), dann gibt es einen Guru. Dies kann man möglicheise dem Programmierer anlasten. Darüber will ich jetzt nicht streiten. CGFX V3 verhält sich anders als P96. Es gibt auf Screens >8Bit nicht -1 sondern irgendeinen legalen Pen zurück. Das Programm wird natürlich auch nicht das machen, was es soll, aber die Gefahr eines Gurus besteht nicht und der Anwender sieht auf dem Monitor, was falsch läuft. Tschüß, [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 16:25 h whose Posts: 2156 User |
Zitat: Das ist schlicht nicht korrekt. Die Autodocs sagen eindeutig, daß die ...Pixel() Funktionen _palettenbasiert_ (pen number!) arbeiten. Das das nun mal nur bei den GraKa-Modi =8Bit und den Amiga-Chipsätzen der Fall ist, ist mehr historisch bedingt. TrueColor-Hardware für den Amiga (Stichwort: AAA) war schon bei C= in der Entwicklung, also wäre das da u.U. auch schiefgegangen, wenn ein bestimmter Modus keine Palette hätte bieten können (24Bit vor allem. 16MB Paletteneinträge?  ).Das man mit WritePixel() oder Set...Pen() einen Palettenwert auch bei Screens >8Bit übergeben kann, ist mehr ein Zugeständnis an die Funktionsweise der aktuellen graphics.library/intuition.library denn gewollt (hast Du Dich schon mal gefragt, warum Du trotz z.B. 24Bit Farbtiefe nur 256 Paletteneinträge hast?). Sämtliche mir bekannten GraKas bieten in den Hi/Trucolor-Modi _keine_ Palette in Hardware an, man wäre hier also auf _vollständige_ Software-Emulation angewiesen (also Emulation einer Palette auch für ReadPixel() und Verwandte), was aber wohl nicht im Sinne des Erfinders ist (Geschwindigkeit?). Die vom PC stammende Hardware für Grafik >8Bit ist schlicht und ergreifend nicht für palettenbasiertes Arbeiten gedacht, also sollte man das auch lassen und den Anwender bitten, einen anderen Screenmode zu wählen oder, noch besser, unter OS3.x gleich die Modi, die keine Palette in Hardware bieten (was bei fast allen GraKas die Modi >8Bit sind), vom "Geschehen" ausschließen. Bedeutet im Umkehrschluß: Läuft Software mit ReadPixel() nicht auf einem Screen >8Bit, hat der Entwickler der Software Bockmist gebaut (ReadPixel() liefert -1? Kann doch gar nicht passieren...), nicht die Entwickler des RTG-Systems. Dem Anwender bleibt aber trotzdem die Möglichkeit, auf einen palettenbasierten 8Bit-Modus auszuweichen, da funktioniert alles wie gewohnt. Auch unter P96. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 21.04.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 19:05 h Tobibrocki Posts: 152 User |
Zitat: Das versteh ich nicht, wie soll das denn gehn ? Zitat: Kuck bitte mal nach, hoffentlich ist es ein standart VGA Kabel ! Zitat: Wie soll ich denn das machen, auf einem eigenen Screen ? Ich bin kein Programmierer, oder hab ich da was nicht verstanden !? Ich benutze zur zeit auf meiner noch vorhandenen CV64/3D ein 15-Bit Modi (800 x 600) ! Ich wollte noch sagen, das The shadow of the third moon (ein Spiel)fehlerhaft darunter läuft (Das Menü ist einwandfrei, aber wenn man ins spiel will, o-ha)! Also, ich kann Programme die für AGA geschrieben wurden auf demselben screen benutzen (ohne zwischen screens herumzuschalten)auf dem sich die Workbench (CV64 Modi) befindet. Wenn man also ein Fenster indem ein AGA Programm läuft (z.B. ein spiel), wessen fenster den gesamten screen bedeckt verkleinert, sieht man die Workbench (welche man dann auch benutzen kann während das AGA Programm weiter seinen dienst verrichtet), oder !? Hab ich das so richtig verstanden ? Zitat: Der MV1200 zeigt den Screen Grünlich an (an einem A4000 angeschlossen), daraus schließe ich, das er nur für den A1200 gedacht ist ! Er ist extern, das ist richtig, funtionieren tut er, aber diese Grüne Bilddarstellung ! -- Der perfekte Platz für einen PC ist die Tonne ! [ Dieser Beitrag wurde von Tobibrocki am 21.04.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
|
2005-04-21, 19:43 h Bluebird Posts: 3260 User |
zu shadow of the third moon das spiel ist nur 8 bit also musst du dem spiel fuer die ingame spielaufloesung auch 8 bit geben das es gut aussieht . die menus haben alle 16bit oder ham bei aga das war schon richtig ... mfg Bluebird [ - Answer - Quote - Direct link - ] |
|
2005-04-22, 01:09 h NoImag Posts: 1050 User |
Zitat: Indem du den Monitorausgang deines Amigas mit dem Eingang der CV64 verbindest. Genauso wie du deinen Amiga ohne Grafikkarte an einem VGA-Monitor betreiben kannst, kannst du statt des VGA-Monitors auch den Eingang der CV64 anschließen. Du brauchst allerdings wie bei einem VGA-Monitor einen VGA-Adapter (war bei meinem A4000 im Lieferumfang). Der CV64 ist es egal, ob das Signal direkt vom Monitorausgang deines Amigas kommt, oder ob es vorher noch von einem Scandoubler aufbereitet wird. Die CV64 sorgt nur dafür, dass du keinen zweiten Monitor oder einen extra Monitorumschalter benötigst. Den Scandoubler benötigst du, weil dein Monitor keine 15kHz-Modi darstellen kann. Mit der CV64 hat das nichts zu tun. Zitat:Zitat: Leider wird das Kabel nicht beschrieben. Aus der Beschreibung der Funktionsweise des Eingangs der CV64 schließe ich aber, dass ein normales VGA-Kabel funktionieren sollte, sofern männlich/weiblich an beiden Enden des Kabels passt. Zitat:Zitat: Du musst nichts programmieren. Die meisten Programme bieten dir die Möglichkeit auszuwählen, ob das Programm seine Fenster auf der Workbench, einem anderen Public-Screen oder einem eigenen Screen öffnen soll (PersonalPaint verwendet z.B. einen eigenen Screen). Wenn du die letzte Möglichkeit wählst, dann kannst du noch einen Screen-Mode auswählen. Diese Wahl ist unabhängig davon, welchen Screen-Mode du für die Workbench eingestellt hast (eventuell darfst du auch angeben "wie Workbench", das darfst du dann natürlich nicht wählen). In der Auswahl findest du alle verfügbaren Screen-Modes. Wenn du eine Grafikkarte hast, dann sind das die AGA-Screen-Modes und zusätzlich die Screens-Modes, die die Grafikkarte liefert. Zitat: Ja. Die Möglichkeit des AmigaOS, gleichzeitig mehrere verschiedene Screens offen zu haben, ist allerdings eines der leistungsstärksten Features des AmigaOS. Ein Feature, das du bei anderen Betriebsystemen vergeblich suchen wirst. Du solltest es nutzen. Es lohnt sich. Zitat: Dazu kann ich nichts sagen, aber ich habe gelesen, dass die Scandoubler für den Video-Steckplatz besser sein sollen als externe Scandoubler. Tschüß, [ - Answer - Quote - Direct link - ] |
|
2005-04-22, 01:26 h NoImag Posts: 1050 User |
Zitat: Das stimmt nicht. Die Autodocs zu ReadPixel sagen: "the pen number of the pixel at (x,y) is returned. -1 is returned if the pixel cannot be read for some reason." Weitere Erläuterungen gibt es nicht. Ich habe auch nochmal extra im NDUK 3.1 nachgelesen. Da steht nirgendwo, dass man damit rechnen muss, dass es irgendwann einamal keine Palette mehr geben wird. Dabei werden Truecolor-Screens ausdrücklich erwähnt. Zitat: Das hat man gemacht, weil bei Vorstellung von CGFX sonst die Workbench nicht mehr als 8 Bit hätte haben dürfen und es bei Einführung auch sonst kein einziges Programm gegeben hätte, das auf Screens >8Bit lauffähig gewesen wäre. Zitat: Dies würde vorraussetzen, dass graphics.library V39 eine Möglichkeit bieten würde herauszufinden, ob ein Screenmode eine Palette hat oder nicht. Diese Möglichkeit gibt es aber nicht. Nur eine Abfrage der Screen-Tiefe wäre möglich. Wie ich oben geschrieben habe, verliert Commodore aber kein Wort dazu, dass dies notwendig sein könnte. Also kannst du auch von einem V39/V40-kompatiblen Programm nicht erwarten, dass es das tut. Zitat: Eben nicht. das Programm wird auch dann nicht laufen, wenn auf -1 getestet wird. Es wird nur keinen Guru geben. Zitat: Dazu muss der Anwender aber wissen, was die Ursache des Problems ist. Das Programm kann es nicht wissen (siehe oben) und dem Anwender darum auch nicht mitteilen. Tschüß, [ - Answer - Quote - Direct link - ] |
|
2005-04-22, 02:45 h whose Posts: 2156 User |
Zitat: Ich such Dir die Stellen bei Gelegenheit mal raus, in denen ausdrücklich steht, daß man _keinerlei_ Annahmen über das Pixelformat eines Screens machen sollte und nicht damit rechnen darf, daß ein Screen immer eine Palette besitzt. Müßte in den Reference Manuals gewesen sein (also schon zu 2.0-Zeiten). Jetzt auf die Schnelle schaff ich das nicht mehr. Andererseits ist das von sich aus schon logisch, weils da z.B. auch noch den HAM-Modus gibt, der auch keine korrekten Palettenwerte liefern kann. Auch wenns kaum einer nutzte, hätte trotz allem die Möglichkeit bestanden, das ein älteres Programm sich mal auf einen HAM-Screen verirrt. Hätte man da Commodore die Schuld geben müssen, wenn das nicht funktioniert hätte? Zitat: Eben. Aus Kompatibilitätsgründen. Allerdings war diese Kompatibilität so nicht geplant, sondern eine Notlösung mangels RTG von Commodore (und ein marktgewinnendes Feature. Die Workbench in 16,8 Mill. Farben, wow!). Frag doch mal Frank Mariak, was er von der Paletten-Emulation wirklich hält... Zitat: Es besteht überhaupt keine Notwendigkeit, daß ein Programm direkt feststellen kann, ob ein Screen eine Palette bietet. Du kannst jederzeit herausfinden, ob Dein Programm in der Lage ist, einen Paletten_wert_ vom Screen zu bekommen oder nicht. Kommt der Wert -1 von ReadPixel(), klappt das nicht. Das Programm kann aus irgendwelchen Gründen nicht arbeiten (welche Gründe das sind, spielt keine so große Rolle. Es geht nicht und fertig!), da es keinen Palettenwert bekommt, und sollte genau das dem Anwender melden. Wozu ist denn der Returnwert -1 von ReadPixel() sonst da? Stürzt das Programm deswegen ab, ists erbärmlich zusammengeklempnert. Zitat: Ach so... also erwartest Du ernsthaft, daß bei jeder OS-oder Hardware-Weiterentwicklung auf Programme Rücksicht genommen wird, die selbst keine Rücksicht auf Programmierkonventionen nehmen oder gar nicht in der Lage sind, von Neuerungen zu profitieren? Dann hätts doch gar keine Grafikkarten gebraucht, die alten Programme nutzen doch eh nur max. 256 Farben... Zitat: Einige wenige hier im Forum bieten immer nur diese Antwort, aber in diesem speziellen Fall sagt sie wirklich alles: Read The F****** Manual! Genau da ist der richtige Ort, um ein paar Bemerkungen des Entwicklers unterzubringen, die dem Anwender bei solchen Problemen weiterhelfen könnten. Ein Satz in der Anleitung genügt: "Bringt das Programm die Fehlermeldung "Bekomme keinen Palettenindex geliefert", sollten sie einen Bildschirmmodus wählen, dessen Farbtiefe 256 Farben oder weniger beträgt.". Besonders viele andere Möglichkeiten gibt es nämlich nicht, die dieses Problem hervorrufen könnten. Damit ist auch das elegant gelöst und das OS kann sich dann sogar einigermaßen ungestört weiterentwickeln. Übrigens: Auch CGFX liefert bei manchen Bildschirmmodi -1 zurück, wenn man den Palettenindex eines Pixels mittels ReadPixel() erfahren möchte. Also genau so gut oder so schlecht wie P96. Darum gings hier ursprünglich... Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2005-04-23, 01:53 h NoImag Posts: 1050 User |
Zitat: Ich habe in den RKRMs nachgelesen. Nach den RKRMs gibt ReadPixel sogar nur dann -1 zurück, wenn der Pixel außerhalb des Rastports liegt. Nach den RKRMs funktioniert ReadPixel auch auf HAM-Screens. Zitat: Natürlich macht eine Palette aus technischer Sicht bei Truecolor keinen Sinn. Darum ging es aber nicht. Es ging um Kompatibilität. Wenn grundsätzlich alte Applikationen auf Screens >8Bit nicht lauffähig wären, wäre das gut zu begründen. Es wurde aber entschieden, das Kompatibilität zu wichtig ist. Dann muss das auch für ReadPixel gelten. Zitat: Du verstehst mich nicht. So wie ReadPixel unter P96 implementiert ist, laufen auch systemkonforme Programme nicht. Das kannst du nicht dem Programmierer anlasten. Wenn Kompatibilität zu systemkonformen Programmen gegeben sein soll und diese ist aber tatsächlich nicht gegeben, dann liegt die Schuld bei der OS-Weiterentwicklung. Es kann bei der OS-Weiterentwicklung sinnvoll sein, die Kompatibilität zu brechen. Dann muss dies aber auch so gesagt werden, also eine Aussage wie "alte Programme laufen unter >8Bit nicht". Zitat: Ich schreibe nicht von Programmen, die heute entwickelt werden, sondern von Programmen, die 1993 entwickelt wurden. Damals konnte noch kein Truecolor-Screen auftreten, also kann dazu auch nichts im Handbuch stehen. Zitat: Bei allen 15, 16 und 24 Bit-Modi meiner CV64, die ich getestet habe, gab es unter CGFX kein -1. Was auf anderen Computern los ist, kann ich nicht wissen. Tschüß, [ - Answer - Quote - Direct link - ] |
| 1 -2- | [ - Post reply - ] |
| amiga-news.de Forum > Amiga, AmigaOS 4 > P96 oder Cgfx3 ? | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2025 by amiga-news.de - all rights reserved. |
|