Zitat:

---

Original von noizejunk:
Und in Sachen Adapter: Ich habe das Teil gekauft mit nem 10cm 2,5" auf 3,5" Kabel. Egal was für ein Kabel (Flach- oder Rundkabel in verschiedenen Längen) ich an den Primary Port anschliesse, die erste Platte startet einfach nicht mehr und ich bekomm den Kickstart-Screen. Dabei ist die Platte genauso gejumpert wie sie eigentlich auch im 1200er läuft.

---

Du versuchst nicht zufällig, eine 2,5"-Platte zusammen mit anderen Geräten an dem 3,5"-Anschluß in nächster Nähe zum 2,5"-Anschluß zu betreiben?

Wenn ja, änder das mal besser. Die anderen Geräte solltest Du dann an den zweiten 3,5"-Port hängen (also der, der am weitesten von dem 2,5"-Anschluß weg ist).

Bei dem 3,5"-Anschluß nahe dem 2,5"-Anschluß handelt es sich um eine Parallelschaltung. Das heißt, dort kannst Du nur dann Geräte problemlos anschließen, wenn der 2,5"-Anschluß unbelegt ist. Hast Du da schon eine 2,5"-Platte dran, mußt Du den anderen 3,5"-Anschluß für weitere Geräte benutzen.

Grüße

--
---

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

Zitat:

---

Original von gni:

Zitat:

---

whose:
Da kann man doch mal erwähnen, daß er die meisten dieser Referenzen per -lauto "erschlagen" kann, wenn er die Libbases nicht von Hand deklarieren und initialisieren will?

---

Wie oft muß noch wiederholt werden, das -lauto bei libnix (-noixemul) _nicht_ verwendet werden muß!? Das wurde bereits x-mal durchgekaut.

---

Zitat:

---

Genau wie das Thema Standard-Funktionen in einer Amiga shared Library. Nur wenige Funktionen können problemlos verwendet werden; stdio, math, etc. gehören _nicht_ dazu.

---

Zitat:

---

Zitat:

---

Das ich auf die Gefahr dieser Lösung bei Amiga-Shared-Libs nicht eingegangen bin, war aber mein Versäumnis. Verzeihung.

---

Nix Gefahr, solche Automatismen greifen nicht (ohne weiteres) in einer shared library.

---

Kannst Du das evtl. mal näher erläutern? Also, wie die Automatismen funktionieren und aus welchen Gründen die in Amiga shared-Libraries nicht greifen? Auch auf die Gefahr hin, daß Du Dich da wiederholen mußt?

Wenn ich da mal offen sprechen darf, genau diese Informationen sind nur sehr schwer (wenn überhaupt) zu finden, wenn man sich die einschlägigen Dokumentationen ansieht...

Grüße

--
---

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

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

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

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

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Da kann Dir aber "-lauto" evtl. weiterhelfen, wenn Du die dos.library nicht von Hand öffnen magst.

---

AAArgh!!
Was soll denn -lauto helfen, wenn man es mit Libraries zusammenlinkt?!
Einmal den freien Fall genießen?

---

Äh, zum Thema Standard-C-Lib-Funktionen und Amiga-Shared-Libraries habt ihr doch schon einiges gesagt. Und Der_Wanderer scheint mit dem GCC noch nicht richtig klarzukommen. Nachher fragt er bei einem ganz normalen Programm nochmal nach, wie man diese Referenzen auflöst. Da kann man doch mal erwähnen, daß er die meisten dieser Referenzen per -lauto "erschlagen" kann, wenn er die Libbases nicht von Hand deklarieren und initialisieren will?

Das ich auf die Gefahr dieser Lösung bei Amiga-Shared-Libs nicht eingegangen bin, war aber mein Versäumnis. Verzeihung.

Grüße

--
---

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

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

Zitat:

---

Original von gni:

Zitat:

---

whose:
Hmm auch fopen() [in vc.lib]?

---

Vorallem das

---

Ah, ok

Zitat:

---

Zitat:

---

Ich frage so dumm, weil ich mich wirklich nur dunkel erinnere... ich hatte die zlib vor ein paar Wochen "mal eben" für den vbcc präpariert und mußte mir dann noch die posixlib besorgen, weil ich eben nicht fertig linken konnte. Und ich meine, das Problem wäre fopen & Co. gewesen. Kann aber auch gut sein, daß ich das falsch in Erinnerung habe. Ich habe mit diesen Funktionen eher selten zu tun.

---

Eventuell lag es an fdopen, das ist keine ANSI/ISO Funktion.

---

Jap, das wars.

@Der_Wanderer:

Für malloc() und Konsorten muß ich hier (vbcc) z.B. nur mit der vc.lib linken, darin sind die Funktionen der Standard-Bibliothek. Beim GCC weiß ich das gar nicht so genau, weil ich den nur extrem selten via Shell eingesetzt habe. Könnte aber libgcc oder so sein, da weiß gni aber wesentlich mehr drüber

Grüße

--
---

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

Zitat:

---

Original von gni:

Zitat:

---

whose:

Zitat:

---

Der_Wanderer:
Hautsächlich Dinge wie malloc, free, fopen etc.

---

Hmm *kopfkratz* wenn ich mich recht entsinne, gehören diese Funktionen zu denen, die beim vbcc in der posixlib vorhanden sind.

---

Falsch erinnert! In der PosixLib sind sie unter Umständen auch drin, aber zu finden sind diese Funktionen in der vc.lib.

---

Hmm auch fopen()? Ich frage so dumm, weil ich mich wirklich nur dunkel erinnere... ich hatte die zlib vor ein paar Wochen "mal eben" für den vbcc präpariert und mußte mir dann noch die posixlib besorgen, weil ich eben nicht fertig linken konnte. Und ich meine, das Problem wäre fopen & Co. gewesen. Kann aber auch gut sein, daß ich das falsch in Erinnerung habe. Ich habe mit diesen Funktionen eher selten zu tun.

Grüße

--
---

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

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

Zitat:

---

Original von Der_Wanderer:
Ich habe jetzt (fast) alles Compilieren können.
Beim Linken bekomme ich aber noch massig unknown references.

Hautsächlich Dinge wie malloc, free, fopen etc.

Wie linke ich die dazu ?

-lamiga habe ich schon angegeben.

---

Hmm *kopfkratz* wenn ich mich recht entsinne, gehören diese Funktionen zu denen, die beim vbcc in der posixlib vorhanden sind. Beim gcc wäre das Pendant dann wohl ixemul oder libnix. Da Du ohne ixemul kompilieren willst, würde ich es an Deiner Stelle mit der libnix probieren, also laut gni dann vermutlich -lnix beim Linken.

Grüße

--
---

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

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

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von Ralf27:
EDIT: Achja, die Farbtiefe, hab ich auch mal testweise angepast, bzw. auch mal ein Bitmap aufgebaut die doppelt so hoch ist wie benötigt und dann geblittet, sodas die bitmap halt gleich ist.

---

Mich deucht, Du hast nicht ganz verstanden, worum es dabei überhaupt ging. Wir reden doch immer noch von einem Fenster auf einem public screen, oder?

Vielleicht solltest Du erst mal Dein Programm ohne double-buffering testen. Wenn Dein Linien Zeichnen an sich schon langsamer als AGA sein sollte, hätte es nämlich kaum Sinn, sich über die Buffer-Strategien den Kopf zu zerbrechen.

---

Du bist aber auch ein unverbesserlicher Pessimist

Ralf hat meines Wissens eine BlizzardPPC samt zugehöriger BVisionPPC. Wenn er die Linien per Move() und Draw() zeichnen läßt, ist diese Kombo garantiert um ein Vielfaches flotter als AGA, auch ohne Offscreen-Bitmap

Das ist selbst die CyberVision64/3D in meinem 1200er im Zorro2-Modus. Geswapt wird da auch nichts, die 8MB RAM der BVisionPPC reichen für einige Spielereien.

Er sollte wirklich mal schauen, wie er seine Offscreen-Bitmap zusammenbaut und vor allem zusehen, daß sie wirklich der Screen-Bitmap entspricht vom Aufbau her.

Eventuell könnte es helfen, die entsprechenden Stellen in seinem Programm zu posten.

@Ralf27:

Zeig doch einmal, wie Du die Bitmap anlegst. Eventuell zeigt sich das Problem dann ohne viel Diskussion. Eigentlich ist das gar nicht so schwierig mit den Offscreen-Bitmaps.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Ja, das ist logisch. Aber was willst Du damit sagen? Ich könnte mir gut vorstellen, daß die RTG-Systeme im Notfall die Screen-Bitmap nur teilweise ins Video-RAM verlagern, wenns gar nicht anders geht.

---

Ach, jetzt auf einmal doch?

---

Nicht "auf einmal". Im Extremfall.

Aber Dein Hinweis auf Offscreen-Tiefe = Screen-Tiefe könnte wohl hilfreich sein

Grüße

--
---

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

Zitat:

---

Aber die Screenbitmap MUSS im Graka RAM liegen, solange der Screen sichtbar ist, sonst sieht man nur ein schwatzes Bild ;-)
Wenn das nicht ins Graka RAM passt, würde der Screen sich nicht öffnen lassen.

---

Ja, das ist logisch. Aber was willst Du damit sagen? Ich könnte mir gut vorstellen, daß die RTG-Systeme im Notfall die Screen-Bitmap nur teilweise ins Video-RAM verlagern, wenns gar nicht anders geht.

Aber wenns anders geht, wäre es ja Blödsinn, nur den (scheinbar) sichtbaren Teil ins Video-RAM zu bringen. Für so schlau halte ich die RTG-Macher schon

Grüße

--
---

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


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

Zitat:

---

Original von Holger:

Zitat:

---

Original von Der_Wanderer:
Für Fullscreen gibt es noch einen Trick, nähmlich einen Screen zu allocieren, der Doppelt so hoch ist wie sichtbar. So ist auf jeden Fall garantiert, dass die versteckte Bitmap im Graka RAM liegt, ohne das Cybergfx oder Picasso die Bitmap swappen kann. Ist allerdings etwas unsauber.

---

Eine solche Garantie gibt es nicht. Da auch weiterhin der Direktzugriff auf BitMaps verboten ist, könnte durchaus auch die zweite Hälfte der BitMap außerhalb der Grafikkarte liegen.
Nur weil Dein System so etwas nicht macht, sollte man nicht gleich von einer Garantie reden. Hohe Wahrscheinlichkeit, bestenfalls.

---

Nein, bei "doppelt hohem Screen" gibt es keine "zweite Hälfte". Da gibt es nur eine durchgehende Bitmap von bspw. 960 Pixeln Höhe statt 480 sichtbaren und 480 unsichtbaren Pixeln in jeweils eigenen Bitmaps.

Entweder liegt diese komplett im Video-RAM oder gar nicht. Es kann durchaus passieren, daß diese Gesamtbitmap einmal ausgelagert wird, aber spätestens, wenn sie wieder (teilweise) sichtbar im Bild ist, wird sie wieder komplett ins Video-RAM verlagert und andere Bitmaps werden dafür im Fast RAM "geparkt". Sollte das nicht möglich sein, bleibt sie im Fast (mit entsprechenden Einbußen in Sachen Geschwindigkeit).

ChangeScreenBuffers() könnte da was anderes ergeben, ist aber auch ein anderes Thema.

Ralfs Problem sieht verdächtig nach fehlendem BMF_MINPLANES aus, ich könnte mir gut vorstellen, daß seine Bitmap im Chip RAM landet, was diese Geschwindigkeitsunterschiede prima erklären würde.

Grüße

--
---

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

Zitat:

---

Original von Reth:
Haaach, nun muss ich das Ding nochmal hochschieben!

Hab gestern seit einiger Zeit mal wieder MLM gespielt und bin deswegen zu spät in die Heia!

Das Game ist noch genau so wie früher: Fesselnd, zeitraubend und suchtelnd (nur noch schnell eine Insel!)!!!

Was für ein schöner Spass!

---

In der Tat, ich spiels auch ab und an gern auf WinUAE, zum Entspannen

Zitat:

---

Wie gesagt ein MLM2 wäre für den neuen Amiga (wenns denn mal einen geben sollte) bzw. AOS4 oder MOS eine tolle Eigenentwicklung (und nicht der X-te C&C-Abklatsch oder ein AOE-Nachbau)!

---

Zitat:

---

Zeitlich hätte ich da kein Problem mit (also wenns mal wieder länger dauert), man denkt ja auch sicher, dass ich an WizardGrounds nichts mehr mache. Stimmt aber nicht, ich machs nur sehr unregelmäßig und die Umbauten verhindern derzeit noch eine Weiterentwicklung.

Insgesamt sind wir Amiganer ja Ankündigungen und Endloswarten gewohnt (erhält bekanntlich die Vorfreude), warum sich dann nicht auf noch was freuen!

---

Ja, wenn Du noch eine Weile warten kannst... im Moment hat Anderes Priorität, was Dir sicher auch gefallen wird, wenns fertig ist. Genaues kann ich nicht verraten (auch keinen Termin), aber lange dauerts nicht mehr, wir sind sehr weit fortgeschritten

Grüße

--
---

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

Zitat:

---

Original von Bluebird:
@whose: hmm deine karte schleift das paula signal nicht durch wenn die lib nicht geladen ist ? , denke mal so extrem ist das auch wieder nicht das ohne dsp garnix tut ...

---

Das habe ich nicht gesagt. Aber schau Dir mal den Verlauf der Leitungen auf der Platine an, dann weißt Du, was ich meine

Der Crystal hat keinerlei Verbindung zum Zorro-Bus und die RAMs auf der Karte ebenfalls nicht. Alles geht in den DSP, der übrigens eine Art "Grundprogrammierung" besitzt, die das "Durchschleifen" (besser: die Initialisierung des Crystal-Chips) wohl erledigt.

Zitat:

---

also echt solangsam denke deine karte hat ne macke

---

Zitat:

---

beim doc iss das ja wieder anders , ab 40er initialisiert die karte nicht mehr wie sie soll d.h. es geht aber sie schmiert eben extrem oft ab !

---

Wie meinen?

Zitat:

---

also wie gesagt meine delfina haengt sich beim booten mit delfinit vielleicht 1x im monat auf bestimmt nicht mehr und das sich der dsp beim mp3 dekoden aufhaengt kommt auch nicht sooft vor , nur wenn ich denn dsp am limit fahre 192 kbps und mehr schmiert sie deutlich oefters ab ...

---

Schlimm genug. Bei der reinen Initialisierung sollte sie eigentlich überhaupt nicht "abschmieren", von daher kann man schon sagen, daß die Delfina zwar zu den guten, aber sicherlich nicht zu den besten Karten zählt.

Klanglich wird sie bei mir jedenfalls von der Toccata deutlich übertroffen. Funktionell sowieso, die Toccata schmiert ja nicht ab

Über die Prelude z.B. habe ich nur Gutes gehört und ich hätte eine erworben, wenn ich eine angeboten bekommen hätte. Aber die Dinger werden ja nur alle Jubeljahre mal angeboten, da ists schwierig dranzukommen.

Repulse kriegt man so gut wie gar nicht.

Grüße

--
---

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

Zitat:

---

Original von Bluebird:
@Dr_Chaotica: delfinit benutzen ! ab 40er ist das sowieso pflicht ! bei mir laeuft das teil perfekt ich musste zwar auch etwa 15 libs testen bis ich eine gefunden hab die mit dem dsp funktionierte aber nun gehts , als ich denn dsp nie genuzt hab hatte ich nie einfrierer .

---

Tja, wenns nur so einfach wäre... ich habe alle Library-Versionen durch und bei allen das gleiche Ergebnis.

DelfInit oder DelfMem, spielt überhaupt keine Rolle.

Mal davon ab, der DSP kommt immer zum Einsatz, nicht nur, wenn Du etwas damit dekodieren läßt oder Filter anwendest oder so. Im simpelsten Fall macht der nichts weiter, als die Daten an den Wandler durchzureichen. Dieser hat nämlich gar keinen direkten Kontakt zum Bus

Grüße

--
---

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

Zitat:

---

Original von Bluebird:
@whose: eigentlich ist mir da nix bekannt das die delfina probleme mit dem zorro 3 des 4000 hat , wobei der zorro 2 modus am 4000 schon ne sache fuer sich ist .

---

Zitat:

---

zum thema toccata vs delfina sag ich jetzt nichts , viele leute schwoeren auf die delfina als absolut beste aber naja ...

---

Da kann ich auch wieder nur mit meinen Karten vergleichen, und in dieser Hinsicht ist klangmäßig die Toccata die eindeutig bessere Karte. Klingt schön "frei" und "luftig", wie die HiFi-Freaks sagen.

Wenn Du es selbst hören und vergleichen könntest, wüßtest Du, was ich meine Ist wirklich ein gewaltiger Unterschied.

Eventuell hat meine Delfina ja auch einen Defekt, man weiß es nicht.

Zitat:

---

laut technischem datenblatt duerfte wohl die repulse mit abstand die beste karte sein die es am amiga gibt aber issja mega selten und wenn dann PIV teuer ...

---

Allerdings. Eine Prelude ist ähnlich schwer zu bekommen, weswegen ich bei der Toccata gelandet bin. Bereut habe ich das bisher nicht, auch wenn man einen "Bogen" anstöpseln muß, um intern-Sound mitzubekommen.

Es gibt schlimmere "Nachteile"

Grüße

--
---

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