[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

Hast Du mal über LockBitMap() nachgedacht? Also, die Riesen-Hintergrund-Bitmap locken, wenn Du die kleineren Bitmaps der Objekte blittest und nach dem Blit der Objekte die Hintergrund-Bitmap wieder unlocken?

Ok, Du wirst es nicht verhindern können, daß die Hintergrund-Bitmap in Extremfällen doch wieder im FastRAM landet (und, noch schlimmer, daß Du sie dann dort festhältst), aber im Allgemeinen sollte die Hintergrund-Bitmap bei der Methode im Video-RAM bleiben.

Blöderweise ist über den Swap-Mechanismus der RTG-Systeme wenig dokumentiert (obwohl das eigentlich in manchen Belangen nötig wäre)...

Edit: Blöde Idee, sehe ich gerade. Man kann zwar graphics.library-Funktionen benutzen, es wird aber nicht gerade empfohlen...

Vertrackte Kiste!

Eventuell wäre Holgers Idee, sich über das verfügbare Video-RAM zu informieren, doch ein Weg? Hat CGFX eine Möglichkeit, über die man an das noch freie Video-RAM kommt?

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Every call to this function MUST be matched with a call to
p96UnlockBitMap or your system will be blocked indefinetely!
Using functions of graphics.library or Picasso96API.library
while holding the lock is possible but should be avoided as
these functions lock the touched bitmaps internally.

---

Naja, gehopst wie gesprungen... eine wirkliche Lösung ist das ja somit nicht.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Hast Du mal über LockBitMap() nachgedacht? Also, die Riesen-Hintergrund-Bitmap locken, wenn Du die kleineren Bitmaps der Objekte blittest und nach dem Blit der Objekte die Hintergrund-Bitmap wieder unlocken?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Hast Du mal über LockBitMap() nachgedacht? Also, die Riesen-Hintergrund-Bitmap locken, wenn Du die kleineren Bitmaps der Objekte blittest und nach dem Blit der Objekte die Hintergrund-Bitmap wieder unlocken?

---

Das wäre ja genau das Gegenteil von dem, was er will. Eine BitMap locken heißt, sie ins FastRAM zu verlagern. Damit man sie mit der CPU bemalen kann. Deshalb sind ja graphics.library-Funktionen in diesem Zustand nicht empfehlenswert. Diese müssten a) mit der CPU oder b) mit je einem FastRAM->GfxRAM und GfxRAM->FastRAM Transfer verbunden ausgeführt werden.

---

Hmm... kann sein, daß ich die P96- wie auch die CGFX-Autodocs da falsch interpretiere, das will ich nicht ausschließen.

Ich habe daraus bisher immer nur gelesen, daß (p96)LockBitMap() verhindert, daß die Bitmap während eines Direktzugriffes möglicherweise ausgelagert wird, eben um einen direkten Zugriff überhaupt erst zu ermöglichen.

Man kann ja auch eine sich bereits im Display befindliche Bitmap locken. Wird die dann wirklich ins Fast RAM ausgelagert für die Dauer des Locks?
Irgendwie kann ich mir das nicht vorstellen.

@Der_Wanderer:

Einen Notnagel könnte ich mir zumindest in der Theorie vorstellen (ich gebe aber keine Garantie für die Anwendbarkeit in der Praxis, ich ahbe das noch nie ausprobiert):

Unterteile die Riesen-Hintergrund-Bitmap in mehrere Teile, 4 z.B. Der Mehrverbrauch an Zeit für die 3 zusätzlichen Blits zzgl. der evt. vorkommenden Swaps für eins oder zwei der Teile könnte dann evtl. unter dem Zeitaufwand für den Riesen-Swap liegen, Zorro z.B. ist ja kein Geschwindigkeitswunder.

Ich gehe mal davon aus, daß die Hintergrund-Bitmap eine Offscreen-Bitmap ist, richtig?

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 20.02.2007 um 02:05 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Also die Riesenhintergrundbitmap ist so gross wie der Screen, z.B. 640x480.
Sie zu unterteilen ist eine gute Idee, nur dann bekomme ich Probleme nahtlos darauf herumzumalen, bzw. ich müsste immer mit verschiedenen offsets auf alle 4 Bitmaps blitten/malen (mit ClipRegion).

---

Zitat:

---

Das mit dem Lock:

Während man einen Lock hält, wird die Bitmap natürlich nicht verschoben, damit man darin herum malen kann. Aber es kann natürlich sein, dass sie ins Fastram geschoben wird wenn man den Lock anfordert.

---

Wie ich schon schrieb, ich kann mir genau das beim besten Willen nicht vorstellen. Man kann ja, wie schon erwähnt, auch eine im sichtbaren Bild befindliche Bitmap locken und darin herummalen, wie wird die denn dann dargestellt, wenn sie sich doch ab dem LockBitMap() im Fast RAM befindet? Der Videochip bzw. die D/A-Konverter können doch dann gar nicht direkt darauf zugreifen und es gäbe ein Riesen-Hin- und Hergeschiebe. Für so beschränkt halte ich die RTG-Entwickler nun wahrlich nicht.

Umgekehrt ist der direkte Zugriff aufs Video-RAM via Zorro für die CPU kein großes Problem, wenn man mal von der arg reduzierten Geschwindigkeit absieht. Die Karten blenden sich mit ihrem Speicher ja meist komplett in den Zorro-Adressraum ein, anders könnten die sichtbaren Bilddaten ja auch gar nicht ins Video-RAM kommen, wenn man mal von "Speicherfenstern" wie z.B. bei den XT/AT-Emulatorkarten (und die PicassoII bot, glaube ich, auch einen 64K-Paging-Modus an, oder irre ich mich da?) absieht und enormer Zeitaufwand beim Übertragen der Daten vermieden werden soll.

Abgesehen davon steht z.B. im P96-Autodoc kein Wort davon, daß die Bitmap beim Lock ins Fast RAM ausgelagert wird, sondern nur, daß eine Aus- bzw. Verlagerung durch den Lock verhindert wird und man sich sputen soll, da ab dem Lock ein Screen-Switching und andere Bitmap-relevante Funktionen, die eine Auslagerung auslösen könnten, bis zum UnlockBitMap() nicht mehr möglich sind. Das könnte ich mir u.A. auch als Grund für die Nicht-Empfehlung der Benutzung der Funktionen der graphics.library vorstellen.

Klingt auch logisch, wenn man bedenkt, daß bei einem Screen-Switch die gerade noch sichtbare Bitmap möglicherweise aus Speichermangel auf der Karte ins Fast RAM ausgelagert werden muß, um die des nun ganz vorn liegenden Screens sichtbar machen zu können.

Ohne die garantierte Nicht-Auslagerung durch den Lock würde das RTG-System der CPU die Beine unterm Hintern wegziehen, wenn ein Direktzugriff auf die erstere Bitmap ausgeführt wird, während genau diese Bitmap gerade vom RTG-System ins Fast RAM ausgelagert wird, weil Platz für die neu sichtbare Bitmap geschaffen werden muß. Die CPU würde dann die gerade neu sichtbar gewordene Bitmap beschreiben, aber nicht die, die sie ursprünglich beschreiben sollte.

Was ich aber in der Tat hinderlich für die Lock-Lösung finde, ist das ausdrückliche Abraten von der Benutzung der Funktionen der graphics.library, obwohl es nicht verboten wurde. Und natürlich, wie Du schon sagtest, daß man ein Auslagern einer bestimmten Bitmap ins Fast RAM nicht ausdrücklich verhindern kann.

Vermutlich hast Du Recht und es geht nur mit der "Holzhammer-Methode" einigermaßen flott, sprich: Höhere Voraussetzungen für die Grafikkarte.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 20.02.2007 um 14:57 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Wie ich schon schrieb, ich kann mir genau das beim besten Willen nicht vorstellen. Man kann ja, wie schon erwähnt, auch eine im sichtbaren Bild befindliche Bitmap locken und darin herummalen, wie wird die denn dann dargestellt, wenn sie sich doch ab dem LockBitMap() im Fast RAM befindet? Der Videochip bzw. die D/A-Konverter können doch dann gar nicht direkt darauf zugreifen und es gäbe ein Riesen-Hin- und Hergeschiebe. Für so beschränkt halte ich die RTG-Entwickler nun wahrlich nicht.

---

Zitat:

---

Umgekehrt ist der direkte Zugriff aufs Video-RAM via Zorro für die CPU kein großes Problem, wenn man mal von der arg reduzierten Geschwindigkeit absieht. Die Karten blenden sich mit ihrem Speicher ja meist komplett in den Zorro-Adressraum ein, ...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Natürlich sagt jetzt keine Spezifikation, wie es wirklich passiert, weil das ja systemabhängig unterschiedlich sein könnte, und was auf System a effizient ist, muss es ja auf System B nicht zwangsläufig auch sein. Aber dass man diese Möglichkeit am Besten gar nicht erst benutzt, das bleibt gleich...

---

Hm, ich denke mal, diese Möglichkeit hat durchaus ihren Sinn, sonst wäre sie nicht bei den "öffentlichen" Funktionen aufgeführt.

Über die Ratsamkeit kann man in einigen Fällen sicherlich prima streiten und ich bestreite gar nicht, daß es Grafikkarten geben mag, die ohne Transfer der Daten ins Fast RAM gar nicht klarkommen. Mir persönlich ist eine solche aber nie untergekommen. Gehört habe ich mal von einer GraKa, die Zorro-Zugriffe auch über ein 64K-"Fenster" abwickeln kann (PicassoII?), um u.A. verträglicher mit Turbokarten in Z2-Systemen zu sein. Das ändert aber nichts daran, daß ein kompletter Transfer ins Fast RAM und zurück das ineffizienteste ist, was man sich vorstellen kann. Grafikkarten für den Amiga unterstützen seltenst DMA-Zugriffe

Was ich z.B. bemerkt habe ist ein ziemlich lahmer Lesezugriff über den Zorro-Bus bei verschiedenen Grafikkarten. Und ein recht fixer Schreibzugriff z.B. auf die CVisionPPC, sofern man selbst eine "Kopie" der zu bearbeitenden Bitmap im Fast RAM hält und diese dann mittels z.B. CopyMem() ins Video-RAM transferiert.

So arbeiten übrigens viele der Ego-Shooter-Ports. Und die sind sogar so nett, vor dem CopyMem() die Bitmap zu locken, damit sie an die Adresse herankommen. Wo wäre der Sinn dieser Vorgehensweise (eine Extra-Bitmap im FastRAM zusammenbasteln und diese dann an die Adresse zu kopieren, die der Lock ergibt), wenn sie (die Bitmap) nach einem Lock doch eh schon im Fast RAM zu finden ist?

Ich weiß ehrlich gesagt nicht, ob es klug ist, zu sagen "das ist nirgendwo spezifiziert, aber gelockte Bitmaps liegen dann im Fast RAM". Da wäre es klüger zu sagen: "Locks nützen Dir nicht viel, es sei denn, Du willst die Heidenarbeit auf Dich nehmen, alle nur denkbaren Pixelformate zu unterstützen und noch dazu statt des Blitters auf die vergleichsweise langsame CPU setzen".

Und bei Der_Wanderer gehe ich davon aus, daß er ein bißchen mehr Durchblick beim Thema hat. Seine Projekte sprechen da eigentlich eine recht deutliche Sprache.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
So arbeiten übrigens viele der Ego-Shooter-Ports. Und die sind sogar so nett, vor dem CopyMem() die Bitmap zu locken, damit sie an die Adresse herankommen. Wo wäre der Sinn dieser Vorgehensweise (eine Extra-Bitmap im FastRAM zusammenbasteln und diese dann an die Adresse zu kopieren, die der Lock ergibt), wenn sie (die Bitmap) nach einem Lock doch eh schon im Fast RAM zu finden ist?

---

Zitat:

---

Und bei Der_Wanderer gehe ich davon aus, daß er ein bißchen mehr Durchblick beim Thema hat. Seine Projekte sprechen da eigentlich eine recht deutliche Sprache.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Weil es ja nunmal keine Garantie dafür gibt, dass sie im FastRAM liegt. Darum geht's ja, Du bekommst durch das locken den Zugriff, aber keinen Garantie, welcher Speicher das nun ist.

---

Hm, eigentlich warst Du es ja, der "landet im Fast RAM" quasi wie ein Gesetz propagiert hat

Aber die ganze Diskussion, und welches Ergebnis die letztendlich hat, hilft beim Thema relativ wenig weiter. Ein Lock auf die Bitmap nützt ihm halt nichts, weil er mit höchster Wahrscheinlichkeit BltBitMapRastPort() o.Ä. einsetzt, von deren Verwendung generell abgeraten wird. Soweit sind wir immerhin schon mal.

Zitat:

---

Der Sinn für die meisten Ego-Shooter liegt allerdings darin, dass der Puffer, mit dem sie rechnen, in einem für's Rechnen optimierten Pixelformat vorliegt, unabhängig davon, in welchem Pixelformat der Bildschirm dann arbeitet. Trotzdem ist natürlich ein Aufruf einer der WritePixelArray-Varianten, die exakt für diesen Zweck vom Grafikkartentreibersystem vorgesehen sind, wesentlich effizienter und systemkonformer, und stattdessen die BitMap zu locken und die Daten von Hand zu kopieren einfach nur dumm.

---

Zitat:

---

Zitat:

---

Und bei Der_Wanderer gehe ich davon aus, daß er ein bißchen mehr Durchblick beim Thema hat. Seine Projekte sprechen da eigentlich eine recht deutliche Sprache.

---

In welcher Hinsicht? Was willst Du damit sagen?

---

Das er sich für z.B. AsteroidsTR sehr eingehend mit dem Thema "Grafikkarten und deren Geschwindigkeit" auseinandergesetzt hat. Und wenn Du Dir das Ergebnis anschaust, sagst Du vielleicht, genau wie ich:

"Wow!"

Also, wenn er etwas zu dem Thema sagt oder fragt, lese ich schon recht aufmerksam mit. Es ist fast immer etwas dabei, was mir bei meinen Vorhaben helfen kann. So auch die Sache mit der Auslagerei der Bitmaps. Bisher habe ich die Auswirkungen davon zwar nicht direkt zu spüren bekommen, aber Gedanken habe ich mir darüber schon gemacht.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Hm, eigentlich warst Du es ja, der "landet im Fast RAM" quasi wie ein Gesetz propagiert hat

---

Zitat:

---

Also, wenn er etwas zu dem Thema sagt oder fragt, lese ich schon recht aufmerksam mit. Es ist fast immer etwas dabei, was mir bei meinen Vorhaben helfen kann. So auch die Sache mit der Auslagerei der Bitmaps.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
> "Wow!"
Danke!

Ja, ich habe schon viel mit Graka rumgespielt, und es ist schon erstaunlich wie "zerbrechlich" das System ist. Ein Flag falsch gesetzt und alles ist gleich nur noch halb so schnell.
Leider verhalten sich die verschiedenen Plattformen aber nicht gleich, deshalb ist es schwer eine Engine zu proggen die überall vernünftige FPS erreicht.

---

Zitat:

---

Das Ergebnis ist in die dbl.include eingeflossen, eine 2D Game API für Amiblitz. AsteroidsTR ist quasi das Demo Spiel dafür. BlackShoot ist glaube ich auch damit gemacht, sonst hat leider noch niemand was damit programmiert. Schade, denn damit ist es ziemlich leicht ein 2D Spiel zu proggen, was selbst auf einem Classic flüssig läuft in 640x480x16 und "smooth" scrollen kann, selbst im Window Modus auf der WB.

---

Zitat:

---

Mit SDL kommt man nie so schnell, weil alles im RAM gebastelt wird und auf die Graka geschoben wird. Bei 320x240 ist da Schluss, zumindest auf dem Classic.

---

Zitat:

---

WritePixelArray solle aber auf jeden Fall gleich schnell oder schneller als ein CopyMem sein. Warum solle es langsamer sein ?
Es ist ja genau für diese Aufgabe gemacht und nutzt u.U. vorhandene Hardware Beschleunigung aus.

---

Das kam durch eine mehr theoretische Betrachtung des Fast RAM-Themas. Wenn das Programm genau aufs Bitmap-Format zugeschnitten rendert, bringt WritePixelArray() keine Vorteile, weil es dann auch nur zu einem CopyMem() führt. Nachteil ist halt, daß noch ein Einsprung mehr nötig ist.

Es spielt erst dann seine Stärken aus, wenn man eben nicht direkt für die betreffende Bitmap berechnet und WritePixelArray() zur Wandlung nutzt.

Allgemein ist das auch der schlauere Weg, den man auf jeden Fall nutzen sollte. Der winzige Nachteil bei direkt passendem Format der Bitmap ist da absolut vernachlässigbar.

Die Hardware-Unterstützung würde sich, sofern die Hardware vorhanden ist, vor allem bei c2p-Konvertierung bemerkbar machen, aber selbst dafür gibt es inzwischen Software-Lösungen, die die Geschwindigkeit des Akiko erreichen (auf der gleichen Maschine) oder manchmal sogar übertreffen. Hardware für die Wandlung von Chunky-Formaten gabs ja nie (war da nicht mal was für die CV64 vorgesehen? Roxxler hieß das Ding, glaube ich).

Streng betrachtet braucht das auch kaum noch jemand, es sei denn, er programmiert direkt für ECS/AGA und rendert im Chunky-Format (Voxelspace-Klamotten fallen mir da auf Anhieb ein).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Hm, eigentlich warst Du es ja, der "landet im Fast RAM" quasi wie ein Gesetz propagiert hat

---

Jeder macht mal Fehler.

---

Zitat:

---

Aber es ging um den logischen Gegensatz: Ziel: "GPU-Zugriff sicherstellen", Funktion von LockBitMap(): "CPU-Zugriff sicherstellen". Das passt nicht zusammen.

---

Zitat:

---

Zitat:

---

Also, wenn er etwas zu dem Thema sagt oder fragt, lese ich schon recht aufmerksam mit. Es ist fast immer etwas dabei, was mir bei meinen Vorhaben helfen kann. So auch die Sache mit der Auslagerei der Bitmaps.

---

Gewiss doch interessant, aber daraus ergibt sich ja keine Lösung. Deshalb ist mir nicht klar, warum Du an dieser Stelle darauf hinweisen musstest.

---

Zitat:

---

In meinen Augen ist es die Aufgabe des Systems, das Auslagern oder nicht Auslagern der BitMaps zu steuern. Nur, wenn P96 es wirklich so macht, wie die hier geschilderten Beobachtungen vermuten lassen, ist es Schrott.

---

Zitat:

---

Gleiches gilt, wenn eine von irgend einem Anwendungsprogrammierer geschriebene manuelle Kopierroutine wirklich schneller sein sollte, als die dafür vorgesehene Transferroutine.

---

Zitat:

---

Zumindest mit CGX+CV64 wurden Pixelformate von der Hardware konvertiert.

---

Zitat:

---

Inwieweit tatsächlich alle Gfx-Karten auf dem Amiga nicht DMA-fähig sind, wie Du behauptest, kann ich nicht verifizieren.

---

Mögliche Kandidaten sind nur reine Zorro3-Karten, alle anderen würden auf den meisten Zorro-Busboards ihren Dienst versagen. Von den beiden reinen Z3-Karten, die es gibt (CV64 und RetinaBLT Z3) weiß ich, daß sie dazu nicht fähig sind. Die C/BVisionPPC muß man dabei außen vor lassen, da ist es schwer von außen feststellbar, ob die DMA-Fähigkeiten betreffs des Mini-PCI-Busses auf der CS/Blizzard-PPC haben. Ich denke aber, daß das nicht der Fall ist.

Ist DMA denn bei PC-Grafikkarten üblich?

@Der_Wanderer:

Bevor ichs vergesse: Hast Du einmal darüber nachgedacht, "unwichtige" kleine Bitmaps im Fast RAM zu halten (mehrere, wenns geht), Dir einen Platz im VRAM für EINE dieser Bitmaps zu sichern (halbwegs, garantiert ist das ja nie) und die Bitmaps bei Bedarf mittels WritePixelArray() in diesen Platz im VRAM zu schieben, bevor sie geblittet werden (oder direkt an ihren Platz zu kopieren)?

Je weniger kleine und kleinste Bitmaps Du im VRAM "zwischenlagerst", auch wenn sie nicht gebraucht werden, desto geringer wird die Wahrscheinlichkeit für eine Auslagerung "im Ringtausch" (wie gesagt, an den Ringtausch glaube ich nicht so ganz. Eher an ein Fragmentierungsproblem).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Ich habe 5 DoubleBuffer Methoden implementiert:

- Single Buffering
- ScrollVP
- ChangeVPBitmap
- ChangeScreenBuffer
- BltBitmapRastPort

Das erste ist natürlich kein DoubleBuffering und flackert, aber der Informatiker braucht sowas halt ;-)

---

Nur die Harten komm' in' Garten

Zitat:

---

Auf WinUAE verhält es sich so:
ChangeScreenBuffer und ChangeVPBimtap sind gleich schnell (z.B. 100FPS), wobei ich ChangeScreenBuffer nie richtig hinbekommen habe, also so dass es nicht flackert. ChangeVPBitmap funktioniert tadellos.

---

Zitat:

---

ScrollVP ist noch einen Tick schneller (110 FPS), am schnellsten mit dem Screenhack (120 FPS), also 2x so hoher Screen statt zwei Bitmaps.

---

Das ist normal ScrollVP() auf eine zweite, unabhängige Bitmap anzuwenden macht auch nicht besonders viel Sinn. Technisch ist es nichts anderes als ChangeVPBitMap().

Zitat:

---

BltBitmapRastPort ist am langsamsten (80FPS), aber immer noch recht ordentlich, und scheint auf allen Systemen einigermassen gleich zu performen. Diese Method braucht man im Window modus.

---

Jup, damit arbeite ich auch. Im Fenster recht schnell, egal, in welcher Farbtiefe. Nur mit maskiertem Blit muß man höllisch aufpassen, habe ich gemerkt. Da sind Offscreen-Bitmaps in Objektgröße immer von Vorteil, aus denen heraus man nach dem Mask-Blit ins sichtbare Bild blittet. Da dürften sich wohl evtl. auftretende Offsets (also abseits von jeweils vollen 16 Pixeln) unangenehm bemerkbar machen...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Im Fall von Grafikkarten und deren allgemein durchgesetztem Aufbau ist es eben nicht wurscht, ob die CPU über den Bus relativ langsam auf Teile der Bitmap im VRAM zugreift oder zuvor genauso relativ langsam aus dem VRAM diese Bitmap komplett ins Fast RAM kopiert, die kleinen Änderungen durchführt und dann den ganzen Käse mit etwas weniger Aufwand wieder zurückschiebt. Direkt ändern ist da sinnvoller.

---

Zitat:

---

Inwiefern? Wegen dem mutmaßlichen Ringtausch (an den ich nicht so ganz glaube, weil auch das keinen Sinn ergäbe) oder weil es durch die CPU zu bearbeitende Bitmaps nicht ins Fast RAM kopiert?

---

Zitat:

---

Bedenke, diese Routinen nutzen oft genug bestimmte Voraussetzungen, die nicht überall gegeben sein müssen. Die WritePixelArray()-Implementation ist schon recht flott. Bei den RGB-Varianten kann man sicher darüber streiten (wurde meines Wissens auch oft getan), aber gar so grottig sind auch die nicht.

---

Zitat:

---

Gabs den Roxxler denn überhaupt? Soweit ich mich erinnern kann, war der angekündigt, kam aber nie. Eine blanke CV64 kann das meines Wissens nach nicht. Ansonsten bleibt nur noch Akiko im CD32.

---

[ - Antworten - Zitieren - Direktlink - ]

@Holger:

Im Moment streiten wir uns irgendwie recht sinnlos über Dinge, die beim Thema nicht weiterhelfen. Daß ein LockBitMap() Der_Wanderer nicht besonders weit bringt, haben wir doch schon längst festgestellt. Sogar ich habe das erwähnt. Zum Thema "ins Fast RAM kopieren" hat auch Georg etwas gesagt.

Der Sinn von WritePixelArray() steht außer Frage, ich benutze es selbst, wenn ich mit Hilfe der CPU Bitmaps bearbeite und diese dann zur Grafikkarte übertragen muß. Einfacher und sicherer gehts kaum.

Zu der CV64 kann ich recht wenig sagen, ich kenne die Karte kaum und alles, was ich dazu geschrieben habe, ist (teilweise unsichtbar) mit "meines Wissens" untertitelt. Es ist gut möglich, daß die tatsächlich eine Formatkonvertierung in Hardware durchführen konnte, eine Art Overlay vielleicht.

Ich habe halt dunkel in Erinnerung, daß für diese Zwecke eigentlich der Roxxler vorgesehen war. Obs 100% stimmt, weiß ich nicht. Ich kann aber gern nochmal in den alten Zeitschriften nachschlagen, wenn ich dran denke.

Absichtlichen Ringtausch der ausgelagerten Bitmaps habe ich in Zweifel gezogen. Hast Du denn dazu noch eine Idee? Ich mein, klingt das denn plausibel für Dich? Wenn ja, wie würdest Du Dir so ein Vorgehen erklären?

Ich z.B. tendiere eher dazu, das mit "Fragmentierung" des VRAMs bei zu vielen, kleinen Bitmaps zu erklären, also, daß es in Wirklichkeit kein Ringtausch ist, sondern eine unglücklich Reihenfolge bei der Nutzung der Bitmaps, die P96/CGFX zum ständigen Austausch aller möglichen Bitmaps zwingt.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
> Flackern oder Durchlauf? Ich wollt Dir sowieso mal ein kleines
> Programm schicken, das mit ChangeScreenBuffer() arbeitet und auf
> dem WinUAE sowie OS4 recht ordentlich aussieht. Ich hoffe, ich
> denke heut Nachmittag dran.
@whose

Danke. Sieht sehr smooth aus.
Um es richtig beurteilen zu können musste aber was Fullscreen scrollen.

---

Zitat:

---

Wie hast du das Timing gemacht? Macht ChangeScreenBuffer das automatisch ?

---

Zitat:

---

Ich habe gesehen, dass du zwei Screen Buffer allocierst, und die dblinfo auch noch selbst. Laut RKM brauch tman aber nur einen Screenbuffer, oder sehe ich das falsch ?

---

die dbi-Struktur brauchst Du auch, da dort die entsprechenden Message-Ports eingetragen werden. Ob das jetzt aber unbedingt notwendig ist, die selbst anzulegen, weiß ich aus dem Stegreif gar nicht.

Ich habe den Code aus comp.sys.amiga.programmer und schon länger nicht mehr angefaßt geschweige denn auf Optimierungsmöglichkeiten hin untersucht. Ich war schon ziemlich froh, daß das überhaupt lief

Zitat:

---

Ich schaue mir nochmal deinen Code genauer an, vielleicht bekomme ich es ja dann auch hin.

---

Dann kannst Du mir evtl. auch bei der Frage weiterhelfen, was ich daran verändert habe, daß es auf dem 4000er mit CGFX so furchtbar flackert

Ich erinnere mich aber lebhaft daran, daß ich etwas im Code verändert hatte auf dem 4000er und das es davor auch dort flackerfrei ablief.

Das Prinzip müßtest Du aber übernehmen können. Ich kann Dir auch noch den Teil mit der Message-Schleife schicken, evtl. wirds dann klarer, wie das funktioniert.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 26.02.2007 um 19:45 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]