amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > ChangeVPBitMap() [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

13.10.2006, 00:14 Uhr

bubblebobble
Posts: 707
Nutzer
Hallo!

Kennt jemand diese Funktion: ChangeVPBitMap() ?

Die ist eigentlich gut geeigent für Doublebuffering,
eigentlich vom OS(3.x) extrra dafür gedacht.
Wird das auch von MOS und OS4 unterstützt, oder geht
das nur auf AGA/OCS screens ?
Könnte da jemand mal im jeweiligen SDK nachgucken ?
Oder hat das vielleicht schonmal jemand verwendet ?

Danke!

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

13.10.2006, 00:53 Uhr

whose
Posts: 2156
Nutzer
@bubblebobble:

Ich habe mal mit dem OS-eigenen DoubleBuffering experimentiert, was ja u.A. ChangeVPBitmap() einsetzt. Das funktioniert auch auf RTG-Systemen (und scheint ganz nebenbei die einzige Möglichkeit zu sein, rasterstrahlsynchrones Scrolling zu bewerkstelligen, aber da kann ich mich durchaus auch irren). Daher gehe ich stark davon aus, daß es auch unter OS4/MOS seinen Dienst wie gewohnt tut.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

13.10.2006, 17:22 Uhr

bubblebobble
Posts: 707
Nutzer
Hm, dann sollte ich das villeicht mal probieren.
Bis jetzt warte ich bis zu einem bestimmten Zeitpunkt und blitte das neu berechnete Bild (was schon auf der Graka ist) über den Screen.

Das geht auch ganz gut, weil der Blit auf allen mir bekannten Grakas deutlich schneller als der Rasterstrahl ist, nur habe ich das Problem den Zeitpunkt zu bestimmen.

Unter WinUAE liefert WaitTOF nur konstant 50Hz, egal welcher Screenmode, WaitBOVP() ist nur gefaked, hat also einen extra Timer der ungefähr die Hz des Bildschirms hat, aber eben nicht 100% synchron läuft, dadurch läuft langsam ein Versatz Balken durch das Bild.

Mehr Möglichkeiten zum Synchronisieren sehe ich leider nicht.

Und bevor hier jetzt einige schreiben "ja, winuae, das ist klar das es kein echten VBlank gibt", soll gesagt sein, dass es unter OS4 genauso ist.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 00:51 Uhr

bubblebobble
Posts: 707
Nutzer
Wen es interessiert:

ChangeVBitMap wird laut RKM für Doublebuffering vorgeschlagen.

Aber:
Unter WinUAE ist es nicht 100% synchronisiert mit dem Bildschirm
und wartet scheinbar immer 2 Bildschirm Frames bis die Bitmap gewechselt wird. Ich suche aber noch, ob ich nicht ein Fehler
gemacht habe.

Siehst aber so aus, als ob es nicht brauchbar ist.

Bis jetzt bringt WaitBOVP auf allen Systemen die beste Leistung,
aber immer noch nicht richtig "smooth".


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 17:49 Uhr

whose
Posts: 2156
Nutzer
@bubblebobble:

Also, ich hatte mal ein Experiment für Sprites gebaut, das läuft auf dem WinUAE eigentlich ziemlich glatt. Ich konnte zumindest nie Zeilenversatz beobachten. Das funktioniert mittels ChangeScreenBuffer(). Eventuell läuft was nicht korrekt bei Deinem Programm.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 17:54 Uhr

bubblebobble
Posts: 707
Nutzer
Gut, ChangeScreenBuffers wäre wieder was anderes.

Ich meine aber RTG Screens auf Graka.
Auf einem 50Hz PAL Screen funktioniert das alles schon, weil die echten Interrupts benutzt werden.
Hast du das auch schonmal auf einem Graka Screen getestet ?


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 18:07 Uhr

bubblebobble
Posts: 707
Nutzer
ChangeScreenBuffers nutzt scheinbar ChangeVPBitMap,
das würde also auf das gleiche hinauslaufen, nur dass ich nicht
alles per Hand allocieren muss.
Evtl. liegt es daran, dass ich das Singal von der Graphics.lib nicht abhole.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 19:58 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von bubblebobble:
ChangeScreenBuffers nutzt scheinbar ChangeVPBitMap,
das würde also auf das gleiche hinauslaufen, nur dass ich nicht
alles per Hand allocieren muss.
Evtl. liegt es daran, dass ich das Singal von der Graphics.lib nicht abhole.


Äh... ja, das solltest Du schon tun. Darauf basiert die ganze Geschichte im Grunde. Ich benutze in meinem Experiment beide Signale, das für "ready to draw to buffer" und das für "ready to change buffers". Das Ganze läuft sowohl auf einem echten Amiga mit GraKa sowie WinUAE mit P96-Screenmode ziemlich glatt.

Das ist zwar etwas langsamer als Direktzugriff, 50fps bekomme ich bei meinem Experiment aber problemlos hin, auch auf dem echten Amiga. Und es läuft halt auch auf dem WinUAE sehr glatt, wie gesagt, ich habe da noch keinen Zeilenversatz gesehen, wenn nicht das gesamte Neuzeichnen via graphics.library durch ein anderes Programm (wie LimpidClock z.B. bzw. alle Programme, die periodisch in kurzen Abständen den WB-Screen locken) angehalten bzw. ausgebremst wird.

Apropos: Weißt Du, weswegen dadurch auch Zeichenoperationen auf einem eigenen Screen ausgebremst werden? Das ist mir irgendwie noch nicht so ganz klar, wie das zusammenhängt...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 20:40 Uhr

bubblebobble
Posts: 707
Nutzer
Also wenn alles richtig läuft, müsstest du exakt die
Bildschirm Frequenz bekommen oder ein ganzzahligen Bruch,
also z.B. 60.3Hz oder 30.15Hz, 20.1Hz usw.
Was dazwischen geht nicht, weil du sonst ein Bild während dem
Screenabtasten switchen würdest.
Das ist ja gerade der Sinn des ganzen. 50Hz auf einem TFT Monitor gehen nicht ohne Flackern/Versatz.
Das dumme an der ganzen Sache ist auch, dass man quasi gezwungen ist
Frameraten-Unabhängig zu programmieren.
Dadurch werden aber dann die Abstände in Pixeln beim Scrollen nicht mehr gleich, also mal 1 Pixel, mal 2 Pixel usw. und es ist wiederum nicht ganz smooth.

Aber wenn du sagst, es hat auf einem Graka Screen funktioniert, werde ich das mal genauer versuchen.

Ein einfaches ChangeVPBitMap erzwingt jedenfalls halbe Bildschirm Hz zahl, wenn man die Signale nicht abholt.
Flackerfrei ist es allerdings nicht, weil es nicht 100% synchron ist.
Deshalb glaube ich auch nicht, dass durch das abholen der Signale das auf einmal flackerfrei wird.

Aber wir werden sehen.

BTW, die schnellste Methode die ich bisher implementiert habe ist, alles komplett im Hintergrund aufzubauane und auf den Bildschirm in einem Rutsch zu blitten. Das scheint schneller als ChangeVPBitMap zu sein. Also nehme ich an, dass auch bei ChangeVPBitMap ein kopiervorgang stattfindet, und nicht nur die Bitmap Pointer ausgetauscht werden, so wie früher auf einem OCS/AGA screen.
(das gilt zumindest für WinUAE)

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 23:04 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von bubblebobble:
Also wenn alles richtig läuft, müsstest du exakt die
Bildschirm Frequenz bekommen oder ein ganzzahligen Bruch,
also z.B. 60.3Hz oder 30.15Hz, 20.1Hz usw.


Gemessen habe ich das nicht. Ich habe nur auf teilweise neu gezeichnete Zeilen geachtet, die tauchen da nicht auf.

Zitat:
Was dazwischen geht nicht, weil du sonst ein Bild während dem
Screenabtasten switchen würdest.
Das ist ja gerade der Sinn des ganzen. 50Hz auf einem TFT Monitor gehen nicht ohne Flackern/Versatz.


Ich sprach auch von fps, das muß nicht notwendigerweise mit der Bildwiederholfrequenz identisch sein.

Zitat:
Das dumme an der ganzen Sache ist auch, dass man quasi gezwungen ist
Frameraten-Unabhängig zu programmieren.
Dadurch werden aber dann die Abstände in Pixeln beim Scrollen nicht mehr gleich, also mal 1 Pixel, mal 2 Pixel usw. und es ist wiederum nicht ganz smooth.


Naja, 100% glattes Scrolling wirst Du vermutlich auch nie bekommen, wenn Du Frameraten-unabhängig bleiben willst. Da spielen ja auch die Frame-Zeiten Deines Programms eine nicht ungewichtige Rolle.

Zitat:
Aber wenn du sagst, es hat auf einem Graka Screen funktioniert, werde ich das mal genauer versuchen.

Es funktioniert definitiv. Ich kann Dir das kleine Ding auch mal zuschicken, samt C-Sourcen.

Zitat:
Ein einfaches ChangeVPBitMap erzwingt jedenfalls halbe Bildschirm Hz zahl, wenn man die Signale nicht abholt.
Flackerfrei ist es allerdings nicht, weil es nicht 100% synchron ist.


Das dürfte wohl daher kommen, weil Dein Programm den Buffer-Tausch nicht synchron erledigt. So, wie ich die Doku dazu verstanden habe, achtet Das System darauf, daß der Bitmap-Wechsel in der Austastlücke stattfindet, sofern das entsprechende Signal beachtet wird. Ansonsten wird der Tausch "brutal" durchgezogen, was in den seltensten Fällen irgendwie synchron abläuft.

Zitat:
Deshalb glaube ich auch nicht, dass durch das abholen der Signale das auf einmal flackerfrei wird.

Aber wir werden sehen.


Eben. Es mag durchaus sein, daß mein Experimentierprogramm durch dummen Zufall so synchron läuft, aber ich glaube nicht so ganz daran, weil es auch auf dem µA1 genauso läuft wie auf den anderen Maschinen.

Zitat:
BTW, die schnellste Methode die ich bisher implementiert habe ist, alles komplett im Hintergrund aufzubauane und auf den Bildschirm in einem Rutsch zu blitten. Das scheint schneller als ChangeVPBitMap zu sein. Also nehme ich an, dass auch bei ChangeVPBitMap ein kopiervorgang stattfindet, und nicht nur die Bitmap Pointer ausgetauscht werden, so wie früher auf einem OCS/AGA screen.
(das gilt zumindest für WinUAE)


Was den UAE angeht, sehe ich das ähnlich. Auf echten Amigas bzw. AmigaOne/Pegasos dürfte aber ein Pointer-Tausch stattfinden. Wäre technisch jedenfalls die sinnvollste Methode und das System hat dort ja den nötigen Zugriff aufs Video-RAM, was beim WinUAE ja nicht unbedingt der Fall sein muß (ich vermute, es ist dort auch nicht der Fall, im Fenster-Modus ist der WinUAE jedenfalls erbärmlich langsam mit der Grafik, da haut ChangeScreenBuffer() auch nicht 100% hin, das klappt nur im Fullscreen).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 23:33 Uhr

bubblebobble
Posts: 707
Nutzer
Zitat:
Zitat:
Was dazwischen geht nicht, weil du sonst ein Bild während dem
Screenabtasten switchen würdest.
Das ist ja gerade der Sinn des ganzen. 50Hz auf einem TFT Monitor gehen nicht ohne Flackern/Versatz.

Ich sprach auch von fps, das muß nicht notwendigerweise mit der Bildwiederholfrequenz identisch sein.
Natürlich nicht. Wenn es "smooth" sein soll allerdings schon.
Mein Test Programm macht auf meiner Hardware "ungebremst" etwa 170 FPS bei 4 Objekten und hintergrund Scolling, also bin ich auf der sicheren Seite. Jetzt muss ich es eben nur noch genau timen, dass es zur richitgen Zeit auf den Screen kommt.
Wenn ich zB. doppelt so oft refreshe wie die Bildschirmwiederholrate, habe ich kein stabiles Bild, weil ich mittendrin die Bitmap vertausche, genauso bei allen anderen Refresh raten die kein ganzzahliger Bruch der Bildschirmrate sind, weil man eben "mittendrin" austauscht und nicht, wenn der Bildschirm gerade fertig ist.
Aber ich weiss schon, mit den "50Hz" wolltest du sagen, dass es recht flott geht, und nicht dass es genau 50Hz sind.
Und ich wollte nur sagen, dass ich erreichen will, dass es ganu dir Bildwiderholrate ist oder ein ganzzahlier Bruch, damit der Bildaufbau stabil erscheint.
Zitat:
Zitat:
Aber wenn du sagst, es hat auf einem Graka Screen funktioniert, werde ich das mal genauer versuchen.

Es funktioniert definitiv. Ich kann Dir das kleine Ding auch mal zuschicken, samt C-Sourcen.

Danke. Ich probiere es erstmal so, und sage hier bescheid, was dabei rausgekommen ist. Wenn esn icht funzt, komme ich auf dein C-Code Angebot gerne zurück.
Zitat:
Zitat:
Ein einfaches ChangeVPBitMap erzwingt jedenfalls halbe Bildschirm Hz zahl, wenn man die Signale nicht abholt.
Flackerfrei ist es allerdings nicht, weil es nicht 100% synchron ist.


Das dürfte wohl daher kommen, weil Dein Programm den Buffer-Tausch nicht synchron erledigt. So, wie ich die Doku dazu verstanden habe, achtet Das System darauf, daß der Bitmap-Wechsel in der Austastlücke stattfindet, sofern das entsprechende Signal beachtet wird. Ansonsten wird der Tausch "brutal" durchgezogen, was in den seltensten Fällen irgendwie synchron abläuft.

Das habe ich mir auch schon überlegt. Allerdings spricht dagegen, dass der "Versatz" langsam über das Bild läuft. Das sieht eher danach aus, als ob der Timer gefaked ist und eine leichte Abwiechung zum echten VBlank hat. Das ist unter WinUAE genauso wie auf dem AOne.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 23:49 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von bubblebobble:

Zitat:
Zitat:
Aber wenn du sagst, es hat auf einem Graka Screen funktioniert, werde ich das mal genauer versuchen.

Es funktioniert definitiv. Ich kann Dir das kleine Ding auch mal zuschicken, samt C-Sourcen.

Danke. Ich probiere es erstmal so, und sage hier bescheid, was dabei rausgekommen ist. Wenn esn icht funzt, komme ich auf dein C-Code Angebot gerne zurück.

Kein Problem.

Zitat:
Zitat:
Zitat:
Ein einfaches ChangeVPBitMap erzwingt jedenfalls halbe Bildschirm Hz zahl, wenn man die Signale nicht abholt.
Flackerfrei ist es allerdings nicht, weil es nicht 100% synchron ist.


Das dürfte wohl daher kommen, weil Dein Programm den Buffer-Tausch nicht synchron erledigt. So, wie ich die Doku dazu verstanden habe, achtet Das System darauf, daß der Bitmap-Wechsel in der Austastlücke stattfindet, sofern das entsprechende Signal beachtet wird. Ansonsten wird der Tausch "brutal" durchgezogen, was in den seltensten Fällen irgendwie synchron abläuft.

Das habe ich mir auch schon überlegt. Allerdings spricht dagegen, dass der "Versatz" langsam über das Bild läuft. Das sieht eher danach aus, als ob der Timer gefaked ist und eine leichte Abwiechung zum echten VBlank hat. Das ist unter WinUAE genauso wie auf dem AOne.

Ja, Moment... hast Du das mit Warten auf das "ready to change buffer"-Signal oder ohne? Bei "ohne" ist es eventuell normal, weil Du dann, wie schon erwähnt, vermutlich den Tausch der Bitmaps erzwingst, und das kann dann halt "irgendwann" sein (wann es der graphics.library genehm ist, aber unsynchronisiert).

Bei "mit" würde ich sagen, liegst Du mit Deiner Vermutung richtig. Dann müßte mein Experiment den Versatz aber auch irgendwann zeigen. Das passiert aber nur, wenn ein anderes Programm periodisch Screens lockt und/oder deren Bitmap ausliest.

Das wiederum nur auf dem WinUAE im "Windowed"-Modus. Im Fullscreen oder auf dem 4000er bzw. µA1 habe ich nur einen Einbruch der Framerate beobachtet, aber kein Rauslaufen aus der Synchronisation, sprich Versatz. Das Ganze allerdings mit ChangeScreenBuffers() und der dazugehörigen Mimik. ChangeVPBitmap() von Hand eingesetzt habe ich nicht. Für ChangeScreenBuffers() braucht man ja nicht besonders viel mehr Aufwand treiben und es ist die empfohlene Methode (wenn auch nicht ganz so fix wie z.B. Direktzugriff).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

17.10.2006, 23:56 Uhr

bubblebobble
Posts: 707
Nutzer
Ja, mal sehen, evtl. helfen die Signale wirklich.

Aber mit ChangeVPBitMap ist es auf jedenfall "irgendwie" gesynced,
also ich bekomme ine Framerate von ca. 60.2Hz, was meinem Screenmodus entspricht. Ungebremst wären es wie gesagt 150+ Hz.
(ungebremst heisst, ich blitte einfach das Bild wenn es fertig ist mit BltBmapRastPort auf den Screen.

BTW mit Versatz meine ich, dass man z.B. bei horizontalem Scrolling einen leichten versatz zischen der oberen und unteren Hälfte des Bildes sieht, weil die obere Hälfte noch das alte und die untere schon die neue Bitmap ist oder umgekehrt.
Bei einem nicht-scollenden Bild sieht man das kaum.
Am auffälligsten ist es bei einem RGB-Fade oder bei Scrolling eben.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

18.10.2006, 00:18 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von bubblebobble:
Ja, mal sehen, evtl. helfen die Signale wirklich.

Aber mit ChangeVPBitMap ist es auf jedenfall "irgendwie" gesynced,
also ich bekomme ine Framerate von ca. 60.2Hz, was meinem Screenmodus entspricht. Ungebremst wären es wie gesagt 150+ Hz.
(ungebremst heisst, ich blitte einfach das Bild wenn es fertig ist mit BltBmapRastPort auf den Screen.

BTW mit Versatz meine ich, dass man z.B. bei horizontalem Scrolling einen leichten versatz zischen der oberen und unteren Hälfte des Bildes sieht, weil die obere Hälfte noch das alte und die untere schon die neue Bitmap ist oder umgekehrt.
Bei einem nicht-scollenden Bild sieht man das kaum.
Am auffälligsten ist es bei einem RGB-Fade oder bei Scrolling eben.


Hmm, dann kann es gut sein, daß das bei den Sprites gar nicht weiter auffällt. Andererseits habe ich gerade einmal sehr genau hingesehen, da läuft kein Versatz durch die Sprites durch.

Eventuell sollte ich das noch mal mit einem weiteren Sprite testen, das sich auch in der unteren Hälfte des Bildes aufhält bzw. bewegt, vielleicht sehe ich dann einen Versatz.

Andererseits müßte der Versatz auch bei dem oberen Sprite sichtbar werden, zumindest im Beginn der Bewegung. Es bewegt sich von rechts nach links, das andere in die andere Richtung und mit negativer Steigung. Aber ich sehe da einfach keinen Versatz, wenn das läuft.

Mal schauen, ich kann das ja auch mal so umbauen, daß die Hintergrund-Tiles alle paar Frames periodisch gegen anders geformte getauscht werden, spätestens dabei sollte ein Versatz dann doch auffallen, oder?

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

18.10.2006, 14:32 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Auf echten Amigas bzw. AmigaOne/Pegasos dürfte aber ein Pointer-Tausch stattfinden. Wäre technisch jedenfalls die sinnvollste Methode und das System hat dort ja den nötigen Zugriff aufs Video-RAM, was beim WinUAE ja nicht unbedingt der Fall sein muß.

Auf's Video-RAM selbst kann WinUAE zugreifen, denn den Puffer dort reinzukopieren ist ja auch ein Zugriff. Aber ein Austauschen von Puffern übersteigt die Möglichkeiten der derzeitigen Implementierung des picasso96 für WinUAE. Da ist insgesamt ne Menge Potential, auch was andere Grafikoperationen angeht.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

18.10.2006, 14:47 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Auf echten Amigas bzw. AmigaOne/Pegasos dürfte aber ein Pointer-Tausch stattfinden. Wäre technisch jedenfalls die sinnvollste Methode und das System hat dort ja den nötigen Zugriff aufs Video-RAM, was beim WinUAE ja nicht unbedingt der Fall sein muß.

Auf's Video-RAM selbst kann WinUAE zugreifen, denn den Puffer dort reinzukopieren ist ja auch ein Zugriff. Aber ein Austauschen von Puffern übersteigt die Möglichkeiten der derzeitigen Implementierung des picasso96 für WinUAE. Da ist insgesamt ne Menge Potential, auch was andere Grafikoperationen angeht.

War etwas unglücklich ausgedrückt von mir, eigentlich meinte ich den Zugriff auf die Grafikchip-Register, um die gewünschte Bitmap ins sichtbare Bild zu bringen.

In Bezug auf WinUAE ist die Frage, ob da überhaupt nochmal eine Implementierung des P96-Treibers mit größerem Potential zu erwarten ist. Das da prinzipiell mehr machbar wäre, habe ich schon länger geahnt, vor allem, wenn ich mir das Schneckentempo im Windowed-Modus so anschaue ;)

Ich habe inzwischen mal ein paar Sprites hinzugefügt, da bewegt sich nun in allen Bereichen des Bildes etwas. Einen Versatz zwischen den beiden Abbildern der Puffer kann ich aber immer noch nicht entdecken. Ist nun die Frage, ob das mehr oder weniger zufällig passiert oder ob das über ChangeScreenBuffers() tatsächlich synchronisiert wird. So richtig klare Aussagen dazu findet man ja dummerweise nirgends...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.10.2006, 21:24 Uhr

bubblebobble
Posts: 707
Nutzer
Also es sieht so aus, als ob sich ChangeVPBitMap und ChangeScreenBuffer auch mit Abholen der Signale nicht anders verhält, also ich habe immer noch einen Versatz und lediglich halbe Bildschirmwiederholfrequenz als FPS.

Dieser Versatz fällt wirklich nur bei scrolling deutlich auf.
Ich versuche daran nochmal etwas zu verbessern.

@whose
Wenns, nicht klappt, kann ich dir ja mal ein demo schicken,
vielleicht ist das ja unter deiner Konfig anders.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > ChangeVPBitMap() [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.