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

amiga-news.de Forum > Programmierung > Transparentz/Alphachannel unter AmigaOS [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

12.12.2005, 17:25 Uhr

bubblebobble
Posts: 707
Nutzer
Hallo Alle!

Hat jemand einen guten Vorschlag, wie man Transparenz implementieren könnte ? Z.B. eine BltBitmapRastPort() version, die von 0-100% Transparenz hat, oder die Transparenz nach einer Alpha Maske regelt ?
Grundsätzlich muss ich ja den RGB Pixel aus dem Rastport auslesen, ihn mit dem Pixel der Bitmap mischen und wieder zurückschreiben.
Dazu könnte man natürlich sowas wie ReadPixel nehmen, aber das ist doch viel zu langsam, wenn es z.B. für ein Spiel verwendet werden soll.
Wie ist das z.B. in Amistart oder MagicMenu gemacht ?
Bis jetzt habe ich eigene Routinen dafür, aber ich muss jedes Pixelformat berücksichtigen, und daher funktioniert das nicht überall. Kann man das irgendwie Pixelformat unabhängig hinbekommen ?

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





[ Dieser Beitrag wurde von bubblebobble am 12.12.2005 um 17:30 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.12.2005, 17:40 Uhr

Blackbird
Posts: 634
Nutzer
@bubblebobble:

Hat das was mit den Problemen deiner Include unter OS4 zu tun ?
Fals ja, sorry, aber ich habe auch noch keine Antwort von Hans-Jörg bekommen :-(

Ich hatte dir ja einen Auszug der Unterstützten Formate zugeschickt, eigentlich müßte das Problemlos funktionieren,aber das tut es leider nicht..

Im OS4depot ist eine alphablit.lib erschienen die OS4 dieses Feature hinzufügt (incl. Source) vieleicht hilft dir das weiter (baut aber auf SDL (?) auf soweit ich mich erinnere)
--

regards
Blackbird

Have a look at:
http://www.blackbird-net.de


Skins for PlayCD OS3.9
BlackShoot, Zombies Apocalypse, GalagaWars
PerfectPaint Catalogs

[ - Antworten - Zitieren - Direktlink - ]

12.12.2005, 18:10 Uhr

bubblebobble
Posts: 707
Nutzer
@Blackbird

Genau, ich frage wegen der image.include.
Das mit dem Abfragen des Pixelformates würde natürlich funktionieren, aber ich möchte eben nicht für alle Formate (und zukünftigen Formate) eine eigene Rotuine schreiben, zumal ich ja nicht nur Transparenz, sondern auch ADD, SUB, Alpha etc. habe, die Anzahl der Funktionen explodiert dann sofort. Ausserdem kann ich nicht alle Formate direkt testen, was das ganze ziemlich erschwert.

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

12.12.2005, 18:25 Uhr

thomas
Posts: 7716
Nutzer
@bubblebobble:

Ich würde Quelle und Ziel mit ReadPixelArray auslesen, zusammenmischen und mit WritePixelArray wieder in das Ziel schreiben. Read/WritePixelArray rechnen automatisch nach/von 24 oder 32 Bit um, vorausgesetzt, die Tiefe ist größer als 8.

So ist z.B. das Crossfading in PicShow realisiert. Ist schnell genug, um ein 800x600-Bild in Echtzeit zu berechnen und 1024x768 mit kaum wahrnehmbarem Ruckeln. (Auf einem A1XE G4 mit 800 MHz).

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

12.12.2005, 19:51 Uhr

bubblebobble
Posts: 707
Nutzer
Aha, ok, das wäre schneller als meine jetzige Methode, wo ich direkt die Pixel mische. Ich werde das mal probieren. Allerdings lese ich da mehr Pixel aus, als unbedingt notwendig sein, z.B. wenn ich ein Bild mit viel transparenz blite. Ich werde es mal probieren und das Ergebnis hier vorstellen.

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

12.12.2005, 20:31 Uhr

Blackbird
Posts: 634
Nutzer
Zitat:
Original von bubblebobble:
Aha, ok, das wäre schneller als meine jetzige Methode, wo ich direkt die Pixel mische. Ich werde das mal probieren. Allerdings lese ich da mehr Pixel aus, als unbedingt notwendig sein, z.B. wenn ich ein Bild mit viel transparenz blite. Ich werde es mal probieren und das Ergebnis hier vorstellen.


ähm, soweit ich das sehe, dürfte das doch gar keine große Rolle spielen bei deiner Image.include, da du bei den CPU_blitbefehlen doch eh nie so große Bereiche hast wie Thomas sie angibt, oder hast du evtl. doch vor ganze Bildschirme per Tranzparenz zu blitten ? evtl so Überblendeffekte zu realisieren ?

Für etwaige Betatests stehe ich gerne zur Verfügung ;-)

PS:
Das bringt mich auf eine weitere Frage, wie steht es überhaupt damit die Kollisionsabfrage zu verbessern/erweitern ?

Im Moment sieht es ja so aus das du immer checkst ob sich die Bilder(mit Tranzparentz) überlappen. Wie wäre es wenn du das etwas umbaust/ausbaust (besser neue Befehle und die alten lassen) und checken kannst ob sich die Bilder wirklich treffen, also die Tranzparenzfarbe subtrahierst und die Pixel collidieren läßt ?

Hätte den Vorteil das man quasi einzelne "Teile" Kollidieren lassen kann und die Kollisionsabfrage so dann genauer wird. Beispiel sei eine Figur die eine andere "treten" will (Kampfszene). Der "Fuß" des einen Objektes trifft den "Kopf" beim Sprungtritt.

Bei der jetzigen Konstellation deiner incude würde der "Kopf" schon lange bevor der "Fuß" diesen trifft eine Kollision ergeben da die Tranzparentz schon den Treffer anzeigt ....

was meinst du dazu ?


--

regards
Blackbird

Have a look at:
http://www.blackbird-net.de


Skins for PlayCD OS3.9
BlackShoot, Zombies Apocalypse, GalagaWars
PerfectPaint Catalogs

[ - Antworten - Zitieren - Direktlink - ]

13.12.2005, 16:10 Uhr

bubblebobble
Posts: 707
Nutzer
@BlackBird:

Naja, je nach Spiel und Größe der Explosionen kann das schon mal ein ganzer Bildschirm voll werden ;-) Speed kann man nie genug haben.

Ausserdem bräuchte ich das für das Faden, da hier immer der ganze Screen durchgenudelt wird. Auf WinUAE funktioniert das ganz gut, weil der Bildschirmspeicher im RAM gepuffert ist, aber z.B. auf Amithlon ist das ziemlich lahm.

Zu der Kollision:
Du meinst, dass man die Bitmaske oder Alphamaske zur Kollisionsberechnugn nutzt ?
Das geht eigentlich schon jetzt, mit image_masktst bzw. dbl_hit,
da kannst du die Objekte pixelgenau abchecken, allerdings nur einen Pixel. Um zwei images tatsächlich mit der Maske kollidieren zu lassen, müsste man alle punkte der Maske durch gehen. Könnte man sicher impelemntieren, ist aber etwas rechenintendiv. Meistens reicht bei einem der images ein "hot-spot", z.B. die Spitze des Schuhs aus, um auf kollision zu testen. Der würde dann überall auf dem Gegnerischen Image Kollision verursachen, wo dieses sichtbar 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 - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Transparentz/Alphachannel unter AmigaOS [ - Suche - Neue Beiträge - Registrieren - Login - ]


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