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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
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.

---

Danke.

Zitat:

---

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

---

Du hast es genau getroffen.

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.

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


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.


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.

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



So, jetzt muß ich aber wieder los, muß noch ein paar Stunden schufte.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Eieiei, den kannte ich noch nicht _hat Notepad von OS4 doch glatt meine gesamten Ergüße zu dem Thema hier verworfen

Also nochmal:

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

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

---

[ - Answer - Quote - Direct link - ]

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Mißverständnis

---

Autsch. Ja, mit der deutschen Sprache steh ich auch auf dem Kriegsfuß.

Zitat:

---

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

---

Also, ich bin eigentlich auch schon so zufrieden wie es jetzt ist. Wenn ich bedenke wie ich angefangen habe die Grafikkarte anzusteuern. Ich hab da wirklich ein ganzes Bild mit WriteRGBPixel aufgebaut... *das* hat gedauert.

Aber jetzt hab ich dank eurer Hilfe wirklich ganz schön an Speed gewonnen.


Mal eine andere Frage:
Ich würde zu gerne wissen was ihr von der eHAM8 und uHAM8-Funktion in meinem Viewer haltet.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:
Mißverständnis

---

Autsch. Ja, mit der deutschen Sprache steh ich auch auf dem Kriegsfuß.

---

Kein Thema

Zitat:

---

Zitat:

---

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

---

Also, ich bin eigentlich auch schon so zufrieden wie es jetzt ist. Wenn ich bedenke wie ich angefangen habe die Grafikkarte anzusteuern. Ich hab da wirklich ein ganzes Bild mit WriteRGBPixel aufgebaut... *das* hat gedauert.

---

Hehe, ja, da kriegt das Wort von der Kaffeepause eine ganz neue Bedeutung

Zitat:

---

Aber jetzt hab ich dank eurer Hilfe wirklich ganz schön an Speed gewonnen.

---

Na, dann haben wir ja schon mal was gewonnen

Zitat:

---

Mal eine andere Frage:
Ich würde zu gerne wissen was ihr von der eHAM8 und uHAM8-Funktion in meinem Viewer haltet.

---

Gute Frage Ich bin noch nicht dazu gekommen, das mal auf meinem AGA-A1200 zu testen. Auf GraKa schon und da läufts ja sehr gut.

Grüße




--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

Zitat:

---

Mal eine andere Frage:
Ich würde zu gerne wissen was ihr von der eHAM8 und uHAM8-Funktion in meinem Viewer haltet.

---

Gute Frage Ich bin noch nicht dazu gekommen, das mal auf meinem AGA-A1200 zu testen. Auf GraKa schon und da läufts ja sehr gut.

---

Danke, das liest man sehr gerne. Aber du hast vermutlich die Version 0.5, und da läuft das mit der Grafikkarte noch relativ langsam. In der Version 0.6 die ich hier habe, sieht es schon wirklich schneller aus. Da wird halt das ganze für die Grafikarte optimal gehandhabt.
In der "alten" V0.6 laufen auch alle BMP-Farbtiefen auf der WB ab 15Bit, was ja bei der V0.5 nur mit 24Bit BMPs möglich war.

Vielleicht wird es ja bald noch schneller.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

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

---

Ich bin neugierig :

Hast du es schon programmiert? Wie läuft es denn? Hab auch seit einiger Zeit nichts mehr am Prog gemacht.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:

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

---

Ich bin neugierig :

Hast du es schon programmiert? Wie läuft es denn? Hab auch seit einiger Zeit nichts mehr am Prog gemacht.

---

Nein, bin leider noch nicht dazu gekommen. Ich hoffe mal, daß ich es dieses Wochenende hinbekomme. Morgen ist ja erstmal Vatertag und dann schon wieder Großkampftag bei Aldi&Co. . Aber ich denke, Samstag sollte es endlich was werden

Grüße


--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Nein, bin leider noch nicht dazu gekommen. Ich hoffe mal, daß ich es dieses Wochenende hinbekomme. Morgen ist ja erstmal Vatertag und dann schon wieder Großkampftag bei Aldi&Co. . Aber ich denke, Samstag sollte es endlich was werden

---

Zja, Feiertag, Vatertag und arbeiten, was für ein Vatertag. So ist es hier in der Familie Schicht und Störung(also im Betrieb, nicht in der Familie selbst! )... hm, grummel. naja.

Was gibt es denn eigentlich jetzt wieder beim Aldi, das es sich wieder lohnt denn Laden zu stürmen?


Nun, bei mir im Programm muß ich auch erst wieder den roten Faden finden. Hab jetzt zwei halbfertige Versionen mit only CGX und komplett, aber "geringem" Speed. Naja, mal sehn wann ich die 0.6 rausbringen kann.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:

Ich hab mich mal drangesetzt:

Quelltext



Programm



Screenshot




Gruß Thomas

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

---

*Danke*

Der Quellcode ist wirklich sehr übersichtlicht und leicht verständlich gemacht. Das C-Programm hab ich komplett (!) verstanden (was selten ist ), aber an einem Punkt hab ich noch Probleme:

bm = AllocBitMap (w,h,24,BMF_MINPLANES|BMF_SPECIALFMT|SHIFT_PIXFMT(PIXFMT_BGR24),NULL);

Die einzelnen Werte sind mir bekannt, aber was macht SHIFT_PIXFMT(PIXFMT_BGR24) ??? Verschiebt SHIFT_PIXFMT denn Wert in der Klammer um die angegeben Bits die in Shift_PIXFMT angegeben sind?
Oder: Was kommt da oben denn als Wert raus?

Edit:
Was w,h und NULL ist, ist mir schon klar. Es geht um die Flags.

[ Dieser Beitrag wurde von Ralf27 am 05.05.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:

Du hast das genau rchtig verstanden. PIXFMT_BGR16 ist 6 und SHIFT_PIXFMT schiebt es um 24 Bits nach links, sodaß da hexadezimal 06000000 herauskommt. Dazu werden dann BMF_SPECIALFMT (00000080) und BMF_MINPLANES (00000010) addiert, sodaß es am Ende 06000090 ergibt.

Gruß Thomas

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

---

Ich hab es eben denn Quellcode von C nach MaxonBasic gewandelt und es läuft! Super!

Übrigens PIXFMT_BGR24: Flag=0A000090

Es ist wirklich einfach, wenn man weis wie. Aber ich wäre nie(!) draufgekommen wie es richtig läuft. Vorallem die Flags-Story.



Danke!

Später werde ich dann denn Uultimativen 24Bit-Highspeedtest machen.

So, jetzt erst mal Pro7 beamen und dann seh ich weiter.

ein kaltes Weizen zur Feier des Tages.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Hab eben Speedtests gemacht und das Ergebniss war leider niederschmetternd:

Also, irgendwas läuft hier falsch, aber wenn ich die Daten ins Format des Screens konvertiere (ARGB, 32Bit, wie der Screen eben), dann erreiche ich bei 800*600*24 eine Datenrate von maximal 10.67MB pro Sekunde(mit BltBitmapRastport. Also genau so schnell wie mit der Konvertierung über CybergraphX(!!!).

Das bedeutet das BltbitmapRastport langsmer ist, bzw. der umweg nix bringt.

Wenn die Konvertierung wärend des blits läuft, dann sackt die Datenrate auf 6MB pro Sek zusammen.

Ich hab also mit meinem Programm und der Konvertierung wärend(!) des Transfer mit CybergraphX das maximal mögliche bei 24Bit rausgeholt (ca. 10MB mit "Realtimekonvertierung").

Ich denk mir mal das das auch zusammenhängt mit dem Pixeltakt der Grafikkarte bei 24Bit.

Ich teste später mal wie das ganze mit 16Bit aussieht.

Aber mal ne andere Frage:

Was bringt 15Bit(32768 Farben) gegenüber 16Bit(65568)? Kompatiblität?
--
http://www.alternativercomputerclub.de.vu

---

Bist Du Dir sicher, das korrekte Pixelformat erwischt zu haben? Ich hab oben immer nur PIXFMT_BGR24 gelesen...

Das wäre zumindest erstmal ein Ansatz, weils eben genauso schnell ist wie mit der "Real Time"-Konvertierung durch CGFX. Logischerweise könnte man da auf den Gedanken kommen, daß immer noch konvertiert wird

Aber ich wußte doch, daß Thomas wieder schneller ist als ein anderer. Und wie immer mit einem Beispiel in gewohnter Qualität

Ich probier das später selber mal aus, dann kann ich Dir vielleicht mehr sagen.

15Bit ermöglicht (in der Theorie) maskiertes Blitten, weil da noch ein Mask-Bit "drin" ist. In Wirklichkeit haben die 15Bit-Modi nämlich auch 16Bit Breite, eben 15Bit für die Farbwerte (5Bit per Gun) + Mask Bit. Ich weiß allerdings nicht genau, ob das mit CGFX/P96 auch unterstützt wird, da die graphics.library da etwas anders arbeitet (extra Maske für Blits).

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Bist Du Dir sicher, das korrekte Pixelformat erwischt zu haben? Ich hab oben immer nur PIXFMT_BGR24 gelesen...

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:
Bist Du Dir sicher, das korrekte Pixelformat erwischt zu haben? Ich hab oben immer nur PIXFMT_BGR24 gelesen...

---

Ich bin mir sicher. Die BVision macht einen Screen mit ARGB auf (11) und wenn ich das Feld so fülle (bzw. so ein Feld aufmache), dann läuft es mit ca. 10MB pro Sek, bei einem anderen Format mit ca. 6MB pro Sek.

Achja, ich rechne da mit 24+Alpha=32Bit=4Bytes pro Pixel.

[ Dieser Beitrag wurde von Ralf27 am 06.05.2005 editiert. ]

---

Hm, tja, dann scheint bei 10MB/sek. das Ende der Fahnenstange zu sein. Ich kann mir zwar im Mom keinen echten Grund dafür denken sondern nur vermuten, aber das is ne andere Sache

Könnte wirklich sein, daß Du da mit der Pixeltakt-Geschichte richtig liegst.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Hm, tja, dann scheint bei 10MB/sek. das Ende der Fahnenstange zu sein. Ich kann mir zwar im Mom keinen echten Grund dafür denken sondern nur vermuten, aber das is ne andere Sache

Könnte wirklich sein, daß Du da mit der Pixeltakt-Geschichte richtig liegst.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:
Hm, tja, dann scheint bei 10MB/sek. das Ende der Fahnenstange zu sein. Ich kann mir zwar im Mom keinen echten Grund dafür denken sondern nur vermuten, aber das is ne andere Sache

Könnte wirklich sein, daß Du da mit der Pixeltakt-Geschichte richtig liegst.

---

Hm, dann compiliere das Prog doch mal bei dir und teste es einfach. Ich hab hier das Prog auf einem BPPC 603e mit 240MHz, 060er/50.

Es scheint mir auch so zu sein das es egal ist was für eine Auflösung das ganze hat. Es sind immer nur ca. 10 MB pro Sek. Egal ob 320*240 oder 1600*1200. Ich tippe hier aber immer von ARGB, bzw. das was die BVision für einen Screen auf macht.

Schreib doch einfach das Programm so um, das z.b. ein Feld von 800*600 generiert wird und dann die Daten 100 mal auf den Screen geschrieben werden. Und dann halt das Ergebniss pro Sek herrausrechnen.

Hinweis: 800*600* 4 Bytes pro Pixel bei ARGB.

Ich würde zu gerne wissen wie das ganze bei der Voodoo aussieht.
--
http://www.alternativercomputerclub.de.vu

---

Ich habs noch nicht selbst compiliert aber das fertige Programm mal angeschmissen. Das dauert zwar ne Sekunde, bis die Bitmap erscheint, aber die Sekunde kommt nicht nur von BlitBitMapRastPort(). Die Sekunde "verbläst" das Programm vor allem beim Füllen der Bitmap (die for()-Schleife inkl. LockBitMap()). Wenn Du also die Zeit über den gesamten Vorgang mißt, mißt Du vor allem anderen die Zeit, die die Schleife zum Füllen der Bitmap braucht. Das hat noch nicht wirklich viel mit der Transferrate zur BVisionPPC zu tun.

Sehen kannst Du das sehr schön an der "Kunstpause", die das Prog nach dem Öffnen des Fensters einlegt. Da ist erstmal nur grau, dann folgt in einem winzigen Augenblick (40stel Sekunde schätze ich, weil man den Aufbau gerade eben noch mitverfolgen kann) die eigentliche Bitmap. Wenn diese Schätzung zutrifft, sieht die Sache schon gleich ganz anders aus.

Ich setz mich später mal dran und meß die Zeit, die BlitBitMapRastPort() hier braucht. Das dürfte vergleichsweise wenig sein.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Ich hab logischerweiße nur die Zeit gemessen die das Kopieren mit BltBitmapRastport dauert.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Ich hab logischerweiße nur die Zeit gemessen die das Kopieren mit BltBitmapRastport dauert.
--
http://www.alternativercomputerclub.de.vu

---

Hm, dann hats was mit der BlizzardPPC zu tun Ich hab etz mal gemessen, BlitBitMapRastPort() braucht bei mir nicht ganz ne 60tel Sekunde, das sind rechnerisch etwas mehr als 17MB/sek. im Transfer. Also ziemlich das, was ich anfangs geschätzt hatte

Grüße
--
---

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


[ Dieser Beitrag wurde von whose am 07.05.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

---

Hm, dann hats was mit der BlizzardPPC zu tun Ich hab etz mal gemessen, BlitBitMapRastPort() braucht bei mir nicht ganz ne 60tel Sekunde, das sind rechnerisch etwas mehr als 17MB/sek. im Transfer. Also ziemlich das, was ich anfangs geschätzt hatte
[/quote]
Ich würde vorschlagen einfachh mal ein größeres Bild (800*600) aufzubauen und dann zig mal zu trans*f*erieren und dann das Mittelmaß zu nehmen. Das ganze hab ich jetzt mehrfach gemacht, aber leider...

Hast Du auch eine 603e mit BVision? Oder die "A4000"-Version? Ich nehme mal an das es da etwas schneller geht.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Ich hab jetzt einige Versuche gemacht, aber ich bekomms nicht schneller hin. Das scheint wohl doch die Schallmauer zu sein.
Das letzt wäre wohl wirklich ein "Hardcore-Direktkopieren" vom Arbeitsspeicher in den Grafikspeicher. Aber das lassen wir dann doch lieber...

Hab leider zur Zeit etwas denn Faden und die Lust verloren. Werde aber hoffentlich bald wieder weitermachen, damit ich mein Programm soweit fertig bekomme, wie ich es auch vor hatte. Zur Zeit liegt es ja leider nur auf der Platte rum und wartet auf die Fertigstellung.

Danke für die Hilfe mit dem Quellcode und dem Backround in Sachen Grafikkarten.

Aber eins hab ich noch:
Der 16Bit-Mode ist ja wirklich recht schnell. Die Farben werde wohl mit 5-5-5 gespeichert. Aber leider hab ich keine genaueren Hinweise wie es genau geht, bzw. welche Bits genau. Ok, RGB bedeutet dann wohl 5R, 5G, 5B. Und der 16te Bit? Ist der am Anfang oder am Ende? Oder hat gar ein Farbkanal ein Bit mehr? Kann mir da jemand genaueren Input geben? (Aber bitte keine Autodocs in Englisch. )

Achja, was bedeutet denn dieses PC bei 15 und 16Bit-Modes?!?

PS: Hab mit dem 16Bit-Mode eigentlich noch nichts richtiges gemacht.

[ Dieser Beitrag wurde von Ralf27 am 16.05.2005 editiert. ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Aber eins hab ich noch:
Der 16Bit-Mode ist ja wirklich recht schnell. Die Farben werde wohl mit 5-5-5 gespeichert. Aber leider hab ich keine genaueren Hinweise wie es genau geht, bzw. welche Bits genau. Ok, RGB bedeutet dann wohl 5R, 5G, 5B. Und der 16te Bit? Ist der am Anfang oder am Ende? Oder hat gar ein Farbkanal ein Bit mehr? Kann mir da jemand genaueren Input geben? (Aber bitte keine Autodocs in Englisch. )

Achja, was bedeutet denn dieses PC bei 15 und 16Bit-Modes?!?

---

Also, das 16. Bit ist "am Anfang", bedeutet, wenn Du Dir die Bits von links nach rechts betrachtest. Also ists das Bit an der "linken Seite".

Das "PC" bedeutet, daß es ein PC-Modus ist, wo die Bytes "vertauscht" sind. Also wäre in diesem Fall das 16. Bit für den Amiga das erste Bit des zweiten Bytes. Alles verstanden?

Das ist die Sache mit der sog. "Endianess". PCs speichern Words (also 16 Bit) "falsch herum", also das niederwertige Byte zuerst, dann das höherwertige.

Grüße


--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Also, das 16. Bit ist "am Anfang", bedeutet, wenn Du Dir die Bits von links nach rechts betrachtest. Also ists das Bit an der "linken Seite".

Das "PC" bedeutet, daß es ein PC-Modus ist, wo die Bytes "vertauscht" sind. Also wäre in diesem Fall das 16. Bit für den Amiga das erste Bit des zweiten Bytes. Alles verstanden?

Das ist die Sache mit der sog. "Endianess". PCs speichern Words (also 16 Bit) "falsch herum", also das niederwertige Byte zuerst, dann das höherwertige.

---

Ok, also ist das PC-Format auf dem Amiga ein recht übles Format, das man nicht benutzen sollte.

Das mit 5-5-5 werd ich später mal versuchen, wenn ich wieder etwas Lust und Zeit habe.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Ok, also ist das PC-Format auf dem Amiga ein recht übles Format, das man nicht benutzen sollte.

Das mit 5-5-5 werd ich später mal versuchen, wenn ich wieder etwas Lust und Zeit habe.

---

Um 15/16Bit PC wirst Du kaum herum kommen, weil viele GraKas nur dieses Format beherrschen

Grüße


--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Um 15/16Bit PC wirst Du kaum herum kommen, weil viele GraKas nur dieses Format beherrschen

---

Oh, meno!
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Mich interessiert diese Bitzusammenstellung auch sehr.
Sehe ich das jetzt richtig, dass ein 16Bit Pixel sich so aufbaut?

1 Bit irgendwas (was? Halfbright?)
5 Bit Rot
5 Bit Grün
5 Bit Blau

Oder geht das noch irgendwie anders?

Ausserdem sagt man doch, 16 Bit sind 65536 Farben.
Mit 5 Bit pro Farbanteil komme ich aber nur auf 32768 (Daher meine Vermutung das eine Bit wäre sowas wie Halfbright yes/no).
Kann mir jemand Quellen angeben, wo ich derartige Fragen (und hoffentlich richtige Antworten ) nachlesen kann?

[ - Answer - Quote - Direct link - ]