Zitat:

---

Original von novamann:

Aber nach dem ich nochmal alles durchgelesen hab, scheint mir das Perlen vor die Säue werfen zu sein, da du meinen/unseren Standpunkt garnicht verstehen willst, da du dir die Sätze gerade zum zitieren für Dich passend zusammenklaubst.

---

Zitat:

---

Also mach ich das mal so:

---

Und ich mache es anders, ich beantworte jeden Absatz einzeln, nur um nicht als jemand dazustehen, der Deine Sätze aus dem Zusammenhang reißt

Zitat:

---

1. Mir und einigen anderen geht es auf den Geist, daß hier zuviel geflamed und getrolled wird, statt auf Fragen einzugehn.

---

Wenn Du genau hinschaust, bist Du mit dem Gefühl beileibe nicht allein. Irgendwie scheint das allen hier so zu gehen, die nicht zu den "Berufsprovokateuren" zählen. Allerdings sind nicht alle der Meinung, daß man das auf die radikale Art beheben muß

Zitat:

---

2. Für die Einhaltung der normalen Umgangsformen zeichnen auch die Mods verantwortlich. Wer sonst sollte so etwas wie Ordnung aufrechterhalten, wenn nicht die.

---

Unter anderem _auch_ die Leute, die diese Ordnung einfordern. Erreichen können sie es, indem sie Pauschal"anklagen" ohne weitere Erläuterungen einfach mal runterschlucken und erst dann etwas kritisieren, wenn sie von der Palme wieder runtergeklettert sind, auf die sie vorher noch raufgeklettert sind in der ersten Wut. Verlangt etwas Selbstbeherrschung (die auch mir manchmal fehlt, wie ich zugeben muß ), ist aber machbar.

Zitat:

---

3. Wenn die ihren Job nicht machen können oder wollen, wird Kritik ja noch erlaubt sein.

---

Wenn Du so freundlich bist, Deine Kritik aufnahmefähig zu vermitteln, hat da bestimmt der große Teil der Forumsteilnehmer rein gar nichts einzuwenden. Klamotten wie "Du taugst nicht als MOD" sind hingegen eher der Polemik zuzurechnen, da platzt manchem (verständlicherweise) der A***h. Meine Meinung zum "Platzen": Siehe Antwort auf den zweiten Absatz

Zitat:

---

4. Wenn das nix hilft, probiern wir mal ne neue Form des Wahnsinns und versuchen dadurch, die User zu sensibilisieren.

---

Zitat:

---

5. Teilweise haben wir unser Ziel ja schon erreicht, die Umgangsformen am Ende von Seite 3 sind ja schon mehr normal alles vieles vorher .

---

Zitat:

---

6. Da das BBoAH nicht in irgendeinem obskuren "Konkurrenzkampf" zur Amiga-News Seite steht, ist ein "Werbung-machen-wollen" so ziemlich das Letzte was dabei herauskommen soll.

---

So kommt es aber rüber. Ist immer ein bißchen mit schalem Beigeschmack, wenn Leutz eine solche Aktion auf einer Seite starten, die selbst eine Art "Community" ist. Da kommt schnell der Verdacht der Mitgliederwerbung mit unlauteren (scheinheiligen) Mitteln auf. Kann man den Jungs nicht verdenken.
[/quote]

Naja, eins hat das Ganze schon mal, was man als "Gut" werten kann: Der Ton ist ruhiger, wenn auch noch nicht wirklich sachlich. Aber es ist zu erkennen, daß man sich hier wenigstens Mühe gibt und nicht den Gefühlen uneingeschränkt freien Lauf läßt. Ich glaube, sowas nennt man "Streitkultur"

Grüße

--
---

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

Zitat:

---

Allerdings muß ich dir rechtgeben wenn du meinst das alles nach OS3.1 eher ein Flickwerk ist. Ich glaube da wird dir bestimmt jeder zustimmen.

---

*hüstel* Du hast aber schon in Rechnung gezogen, daß OS3.9 wesentlich mehr Neuerungen bietet, als OS3.1? Wenn Du das alles bei beiden Versionen gleich haben wolltest, wäre OS3.1 + Zusatzfunktionen noch viel größeres (und inhomogeneres) Flickwerk

Zitat:

---

Wenn ich alleine daran denke wie lange ich brauchen würde um meine OS3.9 Installation so wie sie jetzt ist wieder hin zu bekommen, dann seh ich schwarz. Es ist zwar möglich, aber was für ein Aufwand.

---

Mal die Menge an Daten, die dabei installiert wird, außer acht lassend: Was ist an der Installation von CD so anders als an der von Disketten? Ich brauche für meinen 4000er bei der Installation von OS3.9 nicht entscheidend länger als für die Installation von OS3.1 (ein Hoch auf eine funktionierende Notfall-Diskette!Allerdings nur einmal gebraucht und selbst das noch nicht mal aus Not ). Das "Flickwerk", daß da noch dazu kommt, ist bei beiden gleich (68060.library + Zubehör, CGFX 4 + 4.1, diverse Treiber für IOBlix, Ariadne etc. pp.). Mit der Notfall-Diskette ist aber genau dieses Flickwerk viel schneller wieder auf der Platte als ohne.

Zitat:

---

Teilweise laufen auch mit OS3.9 einige Sachen langsamer als mit OS3.1, z.b. die Workbenchfenster bei Veränderungen am Inhalt. Wenn man da viele Dateien verändern will, dann sollte man das schon im CLI machen, denn sonst gibts ne Kaffeepause.

---

Öhm... welche Art von Veränderung meinst Du da? Ich brauche mit OS3.9 (dank der netten, durchdachten ARexx-Zusatzfunktionen der WB) eher weniger Zeit, um mit meinen Dateien zu hantieren, als unter OS3.1. Veränderungen bspw. der Schutzbits dauert mit der WB von OS3.9 keinesfalls länger als unter 3.1.

Aber das liegt vielleicht auch an der Arbeitsweise und der Aufrüstung des Amigas, die sind ja immer etwas unterschiedlich, je nach persönlicher Vorliebe


Grüße

--
---

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

Zitat:

---

Original von Maja:
Bedenkt das bitte in Zukunft, wenn sich jemand von euch mal wieder dazu aufgerufen fühlt, einen oder die MODs hier mal wieder öffentlich an den Pranger zu stellen, weil wir weder perfekt noch über alle Zweifel erhaben sind.

---

Ich denke, daß war im Ursprung so auch gar nicht gedacht. Desweiteren denke ich, daß der Ruf nach Reglementierung erst aufkam, nachdem das (nicht beachtete) Kind in den Brunnen gefallen war.

Im Grunde erwartet doch keiner, daß gewisse Postings sofort gelöscht werden. Es schadet aber auch nicht, wenn die Moderatoren zu gewissen Postings ganz einfach mal klar Stellung beziehen, und zwar möglichst eine neutrale. Das war hier halt nicht der Fall.

Sebastian steht aufgrund seiner "Verfehlungen" als Flamewar-Starter da, auch bei AC-Pseudo, wie man erkennen konnte. So, wie sich mir das Ganze darstellt, hatte Novamann nur ein Problem mit der fehlenden Neutralität. Das sehe ich nämlich ähnlich. Man kann einerseits nicht jemanden pauschal als Flamewar-Starter hinstellen, weil sowas gegen die Nettiquette ist und andererseits einen Poster, der sich offensichtlich im Ton vergreift, kommentarlos gewähren lassen. Daß sowas einige auf die Palme bringt, wundert mich nicht.

Anstatt das als kleine Mahnung anzunehmen und von MOD-Seite entsprechend zu handeln, wurde gleich das daraus gemacht, was Sebastian möglicherweise beabsichtigte (oder auch nicht). Man schlägt sich hier verbal die Köppe ein und es kommt zu tumultartigen Szenen. Noch dazu werden die mäßigenden Stimmen nahezu ignoriert. Jeder pflegt (wie gehabt) seine Eitelkeit mit immer neuen, an der Sache vorbeigehenden Postings.

Hätte man alles vermeiden können, wenn die oft dargestellte Neutralität auch gleich "gelebt" worden wäre.

Wieder sind _beide_ Seiten gemeint.

Grüße


--
---

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

Zitat:

---

Original von Vigo:
So wie ich es gesagt habe: solche Threads, wo die moralische Keule herumschwingt wird bevorzugt als Trittbrett von den Leuten genutzt, die selber zu genüge "Leichen im Keller haben" (mir fiel jetzt kein weniger dramatischer Spruch ein), was ich einfach nur scheinheilig finde. Und um eines klarzustellen: ich bin auch kein Engel.
--
Jeder User verdient seinen Computer.

---

Ist es nicht normal, daß überall da, wo Moral eine Rolle spielt, auch immer etwas Scheinheiligkeit dabei ist? Das ist aber kein echter Grund, den "Scheinheiligen" das Recht abzusprechen, ihre Meinung zu einem Thema kundzutun. Möglicherweise haben deren Worte, trotz aller Scheinheiligkeit, doch ein paar Körnchen Wahrheit in sich


Grüße

--
---

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

Zitat:

---

Original von CASSIUS1999:

Es ist nicht die Aufgabe eines Moderators, jeden abzumacken, der nicht 100% Forumskonform schreibt. Man kann sicher extrem Hirnis sperren, oder abmahnen. Aber wenn im Forum eine schlechte Stimmumg herrscht ist der beste Modi machtlos.

Jeder muss sich selbst den Schuh anziehen, der ihn passt. Den Modi anzupaulen ist immer am einfachsten. Aber sicher nicht am sinnvollsten.

---

Zum größten Teil hast Du Recht. Andererseits wird auch ein Schuh draus, wenn Die MODs sich nicht anders aufführen als die "bösen" Poster. Es ist doch wirklich kein großes Problem, bei unreflektierter Kritik einfach mal zu sagen, daß der Kritisierende sich dazu doch mal etwas ausführlicher und differenzierter äußern sollte, statt mit dem gleichen Beil in die gleiche Kerbe zu hauen. Damit haben beide den Ast, auf dem sie sitzen (amiga-news.de halt), einfach nur schneller durchgehackt, sonst nichts.

Zum größten Teil geben sich die MODs hier alle Mühe, das stelle ich nicht in Abrede. Aber meiner Meinung nach gehen einige wenige zu schnell an die Decke, wenn man sie kritisiert. Inzwischen müßten die eigentlich gemerkt haben, daß es menschlich gesehen keine einfache Aufgabe ist, die sie sich ausgesucht haben.

Genauso sollten meiner Meinung nach die Nutzer des Forums hier sich immer wieder in Erinnerung rufen, daß es Menschen sind, die sich hier als MODs engagieren, mit allen Schwächen und Fehlern. Dazu zählt eben auch, daß der Mensch gern mit zweierlei Maß mißt, nichts anders hatte Novamann ursprünglich gemeint. Dummerweise hat er das nicht sachlich ausgedrückt, sondern emotional und verzerrt. Insofern ist es verständlich, daß AC-Pseudo ihm in ähnlicher Weise geantwortet hat.

"Richtiger" ist so ein Verhalten deswegen aber nicht. Auf beiden Seiten.

Grüße

--
---

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

Zitat:

---

Original von Ralf27:

Ich glaube da liegt ein kleines Miesverständniss vor:
Ich hab ja immer von MB pro Sek getippt und ich frag mich, wieso sollte der 24Bit (32Bit) Mode nicht auch 50MB pro Sekunde bekommen können?
Jetzt mal ganz trocken:

1600*1200*24 (32Bit)=7,32MB in etwas weniger als 1 Sek=ca.10 MB pro Sek.

Wenn 50MB pro Sek das Maximum ist, dann dürfte doch dann wohl noch das 5 fache an Leistung möglich sein, oder?

Allerdings muß ich eben auch an den Pixeltakt denken, der bei 24Bit geringer ist als bei 16Bit oder gar bei 8Bit. Vermutlich würde das die Bandbreite verringern. Oder hat dies damit nichts zu tun?


Hm,eben ist mir aufgefallen das der 060er die 50MB niemals liefern könnte, da die BPPC nur bis ca. 45MB pro Sek im Speicher transferieren kann.

[ Dieser Beitrag wurde von Ralf27 am 27.04.2005 editiert. ]

---

Mißverständnis

Im Grunde hast Du schon Recht, die Rohdatenrate über den Mini-PCI liegt bei ca. 40MB/sek. Ich hab mich in der Eile auch etwas mistverständlich (und teilweise falsch ) ausgedrückt.

Du hast eine Meßmethode gewählt, die die "Verwaltungsarbeit" des gesamten Systems mit mißt und noch dazu gehst Du von etwas aus, was rein theoretischer Natur ist (24Bit=32Bit. Das stimmt nicht. Da Deine Bitmap immer noch in 24Bit vorliegt, gilt auch immer noch das, was ich unten zu den Zugriffen bei 24Bit schreibe. Deine Annahme gilt erst, wenn Deine Bitmap auch in 32Bit vorliegt. Da habe ich mich auch etwas verwirren lassen, von wegen Hälfte und so).

Bei 16Bit hast Du den Vorteil, daß Du sowohl auf das Bild im Hauptspeicher (in dem das zu tranferierende Bild nun mal liegt) als auch auf den Bus mit "2 Pixeln gleichzeitig" (also 32 Bit) zugreifen kannst. Das bedeutet, daß Du bei gleicher Pixelmenge nur die Hälfte der bei 32 Bit-Pixeln notwendigen Speicherzugriffe benötigst, somit die Datenmenge, die in einem Meß-Zyklus transportiert werden kann, theoretisch am Maximum der Hardware liegt. Aber halt nicht ganz, siehe unten.

Bei 24Bit-Pixeln sieht die Sache schon ganz anders aus. Du kannst z.B. nicht einfach den 24Bit-Wert mit einem Zugriff aus dem Speicher holen, nein, Du brauchst streng genommen 3 Zugriffe dafür (3 Bytes halt). Man könnte hier ein wenig tricksen und doch einen 32Bit-Wert aus dem Speicher lesen und das "überflüssige" Byte dann löschen, aber das würde im Endeffekt nicht besonders viel bringen. Schließlich benötigt das "Löschen" auch ein paar Taktzyklen, die dann halt nicht für den Transfer zur Verfügung stehen. Oder einen Word-Zugriff und einen Byte-Zugriff machen. Hätte aber den gleichen Effekt. Das ist der Hauptgrund, weshalb 24Bit sehr langsam ist.

Bei 32Bit-Pixeln (z.B. BGRA-Bitmap) bräuchtest Du wiederum nur einen Zugriff pro Pixel, aber immer noch doppelt so viele für die gleiche Pixelanzahl, wie bei 16Bit-Pixeln. Die Transferrate bleibt dabei annähernd gleich, also kämst Du auch da theoretisch auch auf ca. 35MB/sek. Allerdings kommen da noch ein paar "Verwaltungsarbeiten" mehr dazu, Unterbrechungen durch andere Transfers z.B. (Zorro). Da Du die Zeit zwischen Eintritt in den Transfer und dem Austritt mißt, zählst Du diese Arbeiten mit, obwohl die nicht unmittelbar zum Grafiktransfrer gehören. Bei doppelter Datenmenge pro Bild (Anzahl 32Bit-Pixel) kommt da also auch die doppelte Zahl an Unterbrechungen hinzu. Rechnerisch erreichst Du somit höchstens drei viertel der möglichen Transferrate (etwas mehr als 20MB/sek., nach Deiner Meßmethode), praktisch eher weniger (also meine angenommenen 17MB/sek.).

Da bei all dem die CPU den Transfer bewältigen muß (die BVision hat keine Busmaster-/DMA-Fähigkeit), beeinflußt die nötige Anzahl der Speicherzugriffe pro Pixel und Unterbrechung unmittelbar die mögliche _tatsächliche_ Transferrate (schließlich kannst Du gewisse Arbeiten wie Zorro-Zugriffe nicht unterbinden).

Der Schluß daraus lautet: Je öfter und länger die CPU auf den Hauptspeicher zugreifen muß, um ein Pixel zu transferieren, desto geringer fällt die _tatsächliche_ Transferrate über den Mini-PCI aus.

Um das Ganze zu überprüfen, miß einfach mal den Transfer bei einem 8Bit-Screen. Die liegt nicht wesentlich höher als bei 16Bit. Warum? Weil 16Bit schon nah an das herankommt, was die Hardware hergibt Nur die Anzahl der Unterbrechungen nimmt noch ab, weil die Menge an Daten pro Meßzyklus noch geringer ist, wodurch 8Bit scheinbar noch ein bißchen mehr Transferrate hergibt. Um die wirkliche Transferrate zu messen, müßtest Du die Zeit messen, die die Übertragung _eines_ Langworts benötigt. Dann wirst Du feststellen, daß zwischen 8 (4 Pixel), 16 (2 Pixel) und 32 (1 Pixel) Bit kein großer Unterschied besteht. Nur 24Bit ist da eine Ausnahme. Im Groben kann man sagen, daß CGFX schon beinahe alles an Speed herausholt, was überhaupt drin ist.

Durch Deine Meßmethode mißt Du, wie gesagt, einiges mit, was nicht zum eigentlichen Transfer auf die GraKa gehört.

Der UWSCSI-Kontroller z.B. ist DMA-fähig (weil nicht über den Mini-PCI angebunden). Der schaufelt die Daten selbständig und schafft so die 45MB/sek. Rohdaten-Transferrate. Im Endeffekt schafft der aber wahrscheinlich trotzdem nur etwas weniger als 40MB/sek., weil er ab und an von der CPU "ausgebremst" wird (konnte ich mangels so schneller Festplatte nie testen).

Versuch halt, es der CPU so einfach wie nur möglich zu machen. Das, was Du dann an Transferrate bekommst, ist nahe am technisch machbaren. Und damit kannst Du dann ziemlich zufrieden sein, denke ich


Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 27.04.2005 editiert. ]

Zitat:

---

Original von Ralf27:

Leider ist es auch so das viel MaxonBasic-Programm aussehn wie C und ich dann dasteh und nur Bahnhof versteh. Genausogut könnte ich dann C lesen, da versteh ich dann fast genau so viel.

Z.b. sind in MaxonBasic auch HOOKs möglich, es gibt sogar extra dafür eine INITHOOK-Funktioon. Aber diese hab ich noch nie benutzt, weil ich es einfach nicht versteh. Und leider ist es auch so das ich so gut wie kein Englisch kann. Es ist eher für mich ein Kampf mich mit den AutoDocs auseinander zu setzen.

---

Thomas hat dazu in nem anderen Thread schon mal eine Erklärung geliefert, die meiner Meinung nach ziemlich vollständig und leicht verständlich ist.

Ich faß es nochmal kurz zusammen:

Hooks sind Funktionen in Deinem Programm, die (nach Bekanntmachung durch z.B. INITHOOK) vom OS in bestimmten Situationen aufgerufen werden können. Bekanntestes Beispiel sind die sog. "Backfill-Hooks", mit deren Hilfe z.B. die Workbench-Fenster ein Hintergrundmuster spendiert bekommen. Speziell für diesen Zweck gibts in der Window-Struktur einen Eintrag, wo man einen Zeiger auf den Backfill-Hook hinterlegen kann (eigentlich ist der Backfill-Hook auch wieder nur eine Strukur). Über diesen Weg kommt das OS an die Adresse Deiner Funktion im Speicher heran und ruft selbige in der passenden Situation sozusagen "zurück" (darum spricht man auch von Call-Back-Hooks).

Ich hoffe mal, das war soweit halbwegs richtig und vollständig, hab mich nie intensiv mit den Hooks beschäftigt

Beachten solltest Du dabei aber, daß man nicht alles in diesen Hook-Funktionen machen kann. Funktionen der dos.library und (soweit ich weiß) auch aller anderen Libraries außer der, die den Hook aufruft, sind tabu (weil ganz einfach nicht bekannt). Somit sind die Möglichkeiten etwas eingeschränkt, aber Hooks sind ja auch nicht für allgemeine Aufgaben gedacht

Zitat:

---

Ich vermute mal, wenn ich Englisch könnte, dann wäre wohl das ganze mindestens 75% leichter für mich.

---

Definitiv

Zitat:

---

Achja, wegen Zeigern:
Es ist da etwa genau so wie in C. Auch in MBasic sind die ganzen Sprünge(Offsets) in denn Includes eingetragen, wie es vermutlich auch in C ist.


Und wegen C lernen:
Ich hab damit mal angefangen, aber wie ich dann mitbekommen habe, das sich sogar die C-Profis über z.b. Addressierungen streiten, hab ich das auch wieder etwas fallen lassen. Aber ganz weg von C lernen bin ich dennoch nicht. Ich muß ja öfters mal C lesen, damit ich versteh wie z.b. einzelne Funktionen eingebunden werden, aber komplexe Zusammenhänge bekomme ich aber so dennoch nicht gebacken.

---

Deshalb solltest Du den Lernaufwand nicht scheuen. Es lohnt sich und interessant ist es allemal

Zitat:

---

Ich würde z.b. auch gerne mal die Bitmap mit dem gleichen FarbFormat füllen wie es der Screen hat und dann in den Screen kopieren(mit denn Systemfunktionen) um nur mal zu sehn wie schnell es geht.

---

Nein, ich will Dich nicht veralbern: Am simpelsten geht das mit WritePixel() (resp. -Array()). Es ist nämlich nicht zwingend, daß eine Bitmap sichtbar sein muß, damit CGFX Daten da reinschreibt. Das kannst Du auch mit x-beliebigen anderen Bitmaps (solange die im ChipRAM liegen und Planar-FOrmat haben, geht das auch mit ECS/AGA). Somit könntest Du die Konvertierung schon beim Laden von CGFX erledigen lassen.

Um besser zu verstehen, was bei der Konvertierung vor sich geht und was alles schiefgehen kann, empfehle ich Dir aber trotzdem, das Konvertieren selbst zu erledigen. Beispiel zu den BitMaps liefer ich, wenn ichs schaff, am Wochenende (kann das grad selbst ganz gut gebrauchen ). Kannst Dich ja schon mal in die BitMap-Geschichte in den CGFX-Docs einlesen. Solltest Du das nicht hinkriegen (weil Englisch), kann Dir das bestimmt jemand übersetzen. Vielleicht ist Thomas wieder einmal schneller mit nem Beispiel, das wäre sogar noch besser. Seine Beispiele sind echt Klasse und waren mir immer sehr hilfreich. Allerdings sind die in C, so wie meine auch

Angriffspunkt Nr. 1 wäre wohl PlanePtr[] in der BitMap-Struktur, allerdings solltest Du dazu die Warnungen in den Docs lesen und verstehen, sonst geht das garantiert ins Auge! Normalerweise geht einen die interne Struktur der BitMap rein gar nichts an, in Deinem Fall machen wir zu Übungszwecken aber mal ne Ausnahme

Zitat:

---

Bei 24bit wäre da von ca. 10MB pro Sek bis 50MB pro Sek noch ne menge Luft.

---

Ich will Deinen Enthusiasmus ja nicht bremsen, aber nach meiner bescheidenen Ansicht ist spätestens bei 20MB/sek. der Ofen aus. Warum? Nun, bei 16Bit hast Du 35MB/sek. errechnet (könnte hinkommen). Ich gehe stark davon aus, daß da der Transfer wegen passender Bitmaps ohne Konvertierungen von statten ging (ein paar kleine Überprüfungen und anschließend Transfer). Da es 16Bit war, konnten mit einem Transfer 2 Pixel auf einmal übertragen werden, was bei 24Bit (32Bit) ja nicht machbar wäre (der Bus ist nun mal nur 32Bit "breit" ). Somit sinkt die mögliche Transferrate bei 24Bit theoretisch schon mal um die Hälfte (sagen wir mal 17MB/sek., wahrscheinlich kommt man bei knapp 16MB/sek. raus). Wenn Du CGFX außen vor läßt und direkt ins VRAM überträgst, kommst Du dann (weil div. Überprüfungen durch CGFX flachfallen) viell. bei 20MB/sek. an, dann ist Sense.

Ganz kannst Du CGFX aus dem Spiel nicht heraushalten, weil dann und wann auch von der GraKa gelesen wird (div. Register des Grafikchips beispielsweise), also wirds wohl eher 18MB/sek.

Ich sags mal so: Wenn Du unter Verwendung der CGFX-Routinen bei bspw. 15MB/sek. mit BASIC ankommst, hast Du schon ne Menge erreicht. Kompatibel bleiben und schnell sein. Das Maximum kannst Du sowieso nicht holen, weil da einige Faktoren eine Rolle spielen, auf die Du keinen direkten Einfluß hast (oder nicht nehmen kannst).


Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 26.04.2005 editiert. ]

Zitat:

---

Original von Mad_Dog:

Zitat:

---

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

---

Keiner will Dein geliebtes BASIC schlecht reden...
Nur leider fragst Du hier immer nach Problemen (wie z.B. Amiga OS API programmierung), die sich in C eben viel einfacher bewältigen lassen, wie in BASIC.

---

Naja, ihm gings wohl mehr darum, daß er ständig das gleiche Sprüchlein zu lesen bekommt: "Nimm C, in BASIC geht das nicht" oder ähnliches.

Das es geht, zeigt er ja mit seinem Programm.

C ist übrigens nicht unbedingt "einfacher". Es ist vor allem "anders". Die meisten BASIC-Dialekte, die mit Zeigern umgehen können, kennen z.B. keine Dereferenzierung oder die beliebige Wandelbarkeit von Arrays in Zeiger + Index oder umgekehrt. Dadurch sehen die BASIC-Programme zwar manchmal komplizierter aus, sind es aber im Endeffekt gar nicht. Es wird z.B. halt nur mit zwei Zeilen ausgedrückt, was man in C in einer Zeile (und mindestens einem Denkfehler ) hätte schreibe können. Mit Strukturen können MaxonBasic (soweit ich weiß) und AmiBlitz (das weiß ich) hervorragend umgehen, die Programme sehen da nicht grundlegend anders aus als in C.

Also kein Grund zu sagen "In BASIC geht das nicht". Einziger Nachteil bei Ralf: Er tut sich schwer damit, Beispielcode in C zu lesen, aber das kriegen wir schon noch hin


Grüße

--
---

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

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

Zitat:

---

Original von Archeon:
Der Druckkopf defekt? Das kann nicht sein, den habe ich im Januar ersetzt! Nachdem nach 3jahren meiner kaputt ging.
Und der Tonerist noch voll. Falsch eingesetzt?? Kann nicht sein.
Ich muss wohl morgen bei http://www.printpac.de anrufen.
Schließlich habe ich ja 6Monate bzw 2 Jahre Garantie :mad:

---

Hm, bei den älteren Tintenspritzern gabs noch eine Canon-eigene Gemeinheit: Wenn das Vlies der Tintenreinigung "voll" war (jeder Reinigungsvorgang wurde in nen druckerinternen Chip geschrieben, ähnlich wie bei Epson-Patronen), wurde der Drucker blockiert (und blinkte selig vor sich hin). Hab nen BJC 6200 vor einiger Zeit weggeschmissen deswegen. Man konnte die Teile zwar resetten (hab darüber mal in der ct gelesen), aber das war mir zu aufwändig und ich hatte keinen Schimmer, wie man das bei nem BJC6xxx macht.

Ich hoff zwar mal, daß das _nicht_ Dein Problem ist, aber wenns das ist...

Grüße

--
---

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

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

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. ]

Zitat:

---

Original von Neodym:

Zitat:

---

Original von whose:
Offtopic:

Zitat:

---

Original von Neodym:
... der Versuch, einen "eigenen" Standard (adaptiertes ReAction) gegen einen etablierten DeFacto-Standard (MUI) durchdrücken zu wollen, ...

---

Noch so einer, der auf die Propagandasprüchlein reingefallen ist und die eisern durchschleppt.

---

Da gibt es nichts reinzufallen. MUI war (ist?) DeFacto-Standard und wurde in 3.5/3.9 nicht übernommen. Dafür brauche ich keine Propaganda, sondern es reicht ein Blick aufs OS...

---

Zitat:

---

Zitat:

---

Frag doch erstmal Stefan Stuntz, warum MUI nicht als "Standard" in OS3.5 übernommen wurde...

---

Nö - ich hab nämlich keinen Bock auf noch so einen kindischen MorphOS vs. AmigaOS-Krieg!

---

Davon habe ich nichts erwähnt. Du hast damit aber gezeigt, aus welcher Ecke der Wind bei Dir weht

Zitat:

---

Die Hintergründe und persönlichen Eitelkeiten interessieren mich als Anwender nicht die Bohne! MUI ist für den Anwender frei verfügbar und kann installiert werden. Wenn man als Distributor eines Softwarepakets keine Lizenz dafür erhält, setzt man das System eben so auf, daß der Anwender diese Installation selbst nachträglich erledigt - ist gängige Praxis.

---

Du weißt aber schon, daß zu Beginn der Entwicklung von OS3.5 (Ende 1997) und sogar noch nach abgeschlossener Entwicklung (Spätsommer 1999) MUI _mitnichten_ frei verfügbar sondern bei regelmäßiger Nutzung registrierungspflichtig war? Noch dazu konnte man es ohne Lizenz nicht auf kommerziellen CDs veröffentlichen. Hätte mans trotzdem getan, wäre man von Stefan Stuntz verklagt worden. _Das_ ist gängige Praxis.

Sicher kannst Du Dir dann auch denken, was passiert wäre, wenn die OS3.5-Kunden hätten doppelt zahlen dürfen (1 Mal OS3.5, 1 Mal MUI) und noch dazu einen eigentlich integralen OS-Bestandteil von Hand nachinstallieren müssen? Sie hätten es nicht gekauft. Ist halt auch gängige Praxis.

Zitat:

---

Zitat:

---

Naja, wenigstens hast Du häufiger erwähnt, daß das größtenteils Deine persönliche Meinung ist

---

Genau - ganz im Gegensatz Du Deinem provokanten "Propaganda"-Sprüchlein weiter oben!

---

Richtig. Und ich kann das "unpersönliche" Sprüchlein sogar mit Tatsachen belegen

Zitat:

---

Zitat:

---

Ontopic:

Tips gabs ja hier nun genug, die alle mal ausprobiert werden sollten. Ich denke, für die Rechnerleistung war nun wirklich alles dabei, was es so an Möglichkeiten gibt. Welche Variante dann zusagt, ist mehr eine Sache der persönlichen Vorlieben.

---

Da stimme ich Dir dann wieder vorbehaltlos zu

Neodym

---

Na, dann hoffen wir mal, daß er all die Anregungen aufnimmt und die passende Kombination für seine Bedürfnisse findet

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

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. ]

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

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

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. ]

Zitat:

---

Original von Neodym:
... der Versuch, einen "eigenen" Standard (adaptiertes ReAction) gegen einen etablierten DeFacto-Standard (MUI) durchdrücken zu wollen, ...

---

Noch so einer, der auf die Propagandasprüchlein reingefallen ist und die eisern durchschleppt. Frag doch erstmal Stefan Stuntz, warum MUI nicht als "Standard" in OS3.5 übernommen wurde...

Naja, wenigstens hast Du häufiger erwähnt, daß das größtenteils Deine persönliche Meinung ist

Ontopic:

Tips gabs ja hier nun genug, die alle mal ausprobiert werden sollten. Ich denke, für die Rechnerleistung war nun wirklich alles dabei, was es so an Möglichkeiten gibt. Welche Variante dann zusagt, ist mehr eine Sache der persönlichen Vorlieben.

Grüße


--
---

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

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. ]

Zitat:

---

Original von NoImag:

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.

---

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

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

Zitat:

---

Original von NoImag:

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.

---

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. ]

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

Zitat:

---

Original von NoImag:

Zitat:

---

Original von whose:
Soweit ich weiß, besitzt die CV64 keine 3D-Hardware, wäre daher also der CV64/3D bei 3D automatisch unterlegen.

---

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:

---

Zitat:

---

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.

---

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:

---

Zitat:

---

Ebenso Software, die von Planar-Grafik ausgeht, ohne diese ausdrücklich anzufordern.

---

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.

---

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

Zitat:

---

Original von NoImag:
Die CV64 war allgemein in Tests immer besser als die CV64/3d. Wie das bei 3D-Spielen aussieht, weiß ich aber nicht, weil ich nicht spiele.

---

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

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