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

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

-1- [ - Beitrag schreiben - ]

03.01.2011, 22:06 Uhr

AGSzabo
Posts: 1663
Nutzer
hi,

für mein menu überleg ich noch wie man da eine teilweise transparenz des hintegrundes realisieren könnte. hat jemand eine idee oder weiss wie?

ags
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

03.01.2011, 23:02 Uhr

Thore
Posts: 2266
Nutzer
Ich hab mal so Pseudotransparenz gemacht. Hab ne Grafik-Lib gemacht die sowas kann. Dabei hab ich einfach zwei Bilder miteinander verrechnet.
Also die Farbwerte erst durch 50 geteilt und dann miteinander addiert.
Damit hatte ich 50% transparenz. Ging aber nur mit Gfx Karten modus so.

[ - Antworten - Zitieren - Direktlink - ]

03.01.2011, 23:05 Uhr

AGSzabo
Posts: 1663
Nutzer
@Thore:

punkt für punkt, oder?
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

03.01.2011, 23:16 Uhr

RhoSigma
Posts: 67
Nutzer
Nimm mal Verbindung mit den Autoren von MagicMenu v2.35 auf, die haben da sowohl die Möglichkeit einer transparenten Farbe wie auch die Verwendung transparenter Hintergründe (Backfill images) eingebaut, d.h. die sollten wissen wie's geht...

[ - Antworten - Zitieren - Direktlink - ]

03.01.2011, 23:26 Uhr

Thore
Posts: 2266
Nutzer
@AGSzabo:
Ja punkt für Punkt, wenn Du 32 Bit Werte hast kannst Du sowieso nur 1 Pixel gleichzeitig berechnen.

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 17:30 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
punkt für punkt, oder?

Auf Classic-Amigas gibt's nur punkt-für-punkt, wobei man das dann sowohl für P96 und CGX implementieren müsste, wenn man alle unterstützen will, oder optional den Umweg über Warp3D.
Oder man legt ein Raster über das Bild, was natürlich nur mäßig aussieht, bei CLUT-Modes also insb. bei ChipSet-Grafik die einzige Möglichkeit ist, zumindest solange alles systemkonform und im angemessenen Ressourcen-Rahmen bleiben soll.

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

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 18:03 Uhr

akl
Posts: 265
Nutzer
@AGSzabo:

Steht eigentlich alles hier:
http://de.wikipedia.org/wiki/Alpha_Blending

Die entscheidende Formel ist:

pixel = alpha * x + (1 - alpha) * y

Dass alpha nicht zwischen 0..1 liegt, sondern zwischen 0..255 - und dass x,y jeweils ebenfalls innerhalb 0..255 für R,G,B getrennt vorliegen, sollte klar sein. Deshalb muss auch pixel nochmal durch 255 geteilt werden und sichergestellt sein, dass das Ergebnis immer zwischen 0..255 liegt...

Eine optimierte Berechnung dafür bekommst Du sicher selbst hin, und ggf. einen Lookup-Table um die Multiplikationen einzusparen...

Viel Spass :-)

[ Dieser Beitrag wurde von akl am 04.01.2011 um 18:06 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 20:41 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Du brauchst eine Weiche, ob es ein farb-indizierter Screen ist oder Echtfarben.

Bei Echtfarben liesst du mit ReadPixelArray() den Hintergrund in einen Speicherbereich mit fixem Pixelformat, z.b. ARGB. Dann verrechnest du Pixel für Pixel die Daten und schreibst das mit WritePixelArray zurück.

Bei farb-indizierten Bildschirmen geht das nicht, da man den Pen nicht so enfach ermitteln kann. Das geht zwar auch, ist aber etwas rechenaufwendiger. Wenn man in Betracht zieht, das praktisch alle schnellen Systeme 16 oder 24 bit benutzen, und bei einem farb indizierten Screen eine eher langsame CPU darunter werkelt, kann man sich das sparen und kann nur on/off transparenz machen.

So mache ich das mit den Skins (und allen anderen Grafiken) in NTUI, z.b. hier in der Sprechblase:

Bild: http://www.hd-rec.de/pics/ntui_status16.png

Ein wichtiger Aspekt ist noch die re-draw Stategie, denn man darf nicht wie bei on/off transparent ein Bild zweimal auf den gleichen Fleck zeichnen. Man muss also jedesmal vom Fenster Hintergrund beginnen und alle sich überlappenden Elemente neu zeichnen.
Das kann man später evtl. etwas optimieren, aber so musst du das von gund auf erstmal machen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 04.01.2011 um 20:45 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 21:17 Uhr

akl
Posts: 265
Nutzer
@Der_Wanderer:
Alpha-Effekte auf 8 Bit-Screens halte ich generell nicht für eine so besonders gute Idee, weil man für jede berechnete Transparenz eigentlich einen eigenen Pen allozieren müsste - wenn sich also 16 Pixel unterschiedlicher Farbe mit 16 anderen Pixeln unterschiedlicher Farbe überlagern, braucht man unter Umständen nochmal 16 Pens für die Transparenz...

Wenn's eine Arbeitsoberfläche ist und der vorherrschende Farbton einfarbig ist (Grau-/Blau-/Grüntöne oder ähnlich) dann sieht's vielleicht dennoch einigermaßen aus...

Wär's nicht sinnvoller, auf halbgare Transparenz bei 8 Bit besser ganz zu verzichten?!

[ Dieser Beitrag wurde von akl am 04.01.2011 um 21:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 22:13 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@akl
Schreib' ich doch.
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 22:31 Uhr

Thore
Posts: 2266
Nutzer
Ich hab mal ne gfxman.lib gebaut, da kann ich dir bei Gelegenheit mal zeigen wie ichs da gemacht hab. Da gibts auch Transparenz und das auch recht flott. Pixel für Pixel Berechnung aber mit Gfx Karte eben.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 11:35 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@Thore
Wie hast du das denn gemacht?
Anders als ich geschrieben habe? (Read/WritePixelArray) Evtl. kann ich noch was lernen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 12:14 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Anders als ich geschrieben habe? (Read/WritePixelArray) Evtl. kann ich noch was lernen.

Zumindest bei CGX gibt es die Möglichkeit, eine Hook-Funktion direkt auf den Grafikspeicher anzuwenden, vorausgesetzt, man kann das aktuelle Pixelformat unterstützen und behandelt das Clipping korrekt.

Ich würde bei so einer Vorgehensweise die allgemeine R/WPA Variante als Fall-Back behalten.

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

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 12:15 Uhr

Thore
Posts: 2266
Nutzer
@Der_Wanderer:
Ich hab schon die API Funktionen für CGX verwendet (bei P96 sind diese auch über die eingebaute Emu verwendbar), weil ich mir den Stress mit dem Umrechnen der Pixelformate sparen wollte. Ich glaube das war auch WritePixelArray, ist aber schon ne Weile her so daß ich es nicht mehr genau weiß.
Die Berechung der 24 Bit Pixel-Werte hab ich jedoch selbst gemacht.
Kann dazu die Funktion mal posten. Heute abend wenn ich dazu komm.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 12:15 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von akl:
@Der_Wanderer:
Alpha-Effekte auf 8 Bit-Screens halte ich generell nicht für eine so besonders gute Idee, weil man für jede berechnete Transparenz eigentlich einen eigenen Pen allozieren müsste - ...

Wenn es sich um einen Public Screen handelt...

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

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 14:02 Uhr

akl
Posts: 265
Nutzer
@Holger:
Wie meistens ;-) sind die Anforderungen hier ja nicht klar definiert, aber bei einem universellen OOP-Menüsystem darf man wohl von einem PublicScreen als zumindest der wahrscheinlicheren Variante ausgehen.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 14:04 Uhr

akl
Posts: 265
Nutzer
@Der_Wanderer:

>Schreib' ich doch.

Hm, stimmt ;-) Ich würde allerdings weniger mit dem Rechenaufwand argumentieren, als mit dem zu erwartenden visuellen Ergebnis.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 18:42 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von akl:
@Holger:
Wie meistens ;-) sind die Anforderungen hier ja nicht klar definiert, aber bei einem universellen OOP-Menüsystem darf man wohl von einem PublicScreen als zumindest der wahrscheinlicheren Variante ausgehen.

Die universelle Zielstellung könnte ich vielleicht auch noch unterstellen, aber dass es tatsächlich eine andere Person als der Autor nutzt, halte ich dagegen derzeit für äußerst unwahrscheinlich. Insofern sind Public Screens keine Notwendigkeit.
Zitat:
Ich würde allerdings weniger mit dem Rechenaufwand argumentieren, als mit dem zu erwartenden visuellen Ergebnis.
Letztendlich zählt meistens das Verhältnis dieser beiden Größen. Wobei auch das schönste visuelle Ergebnis nichts zählt, wenn der Rechenaufwand zu hoch ist.


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

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 19:44 Uhr

Thore
Posts: 2266
Nutzer
verdammt, mein Amiga geht nicht mehr, die Platte rattert vor sich hin und nichts geht mehr, shit verdammter :(

[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 10:07 Uhr

Thore
Posts: 2266
Nutzer
Yay ich hab noch ein Voll-Backup meiner gesamten Platte gefunden :)

Hier ein Beispiel für 50% Transparenz aus der Lib:
code:
/*BltRastPortTrans  
  Blittet RastPort-Ausschnitt halbtransparent zu 50% */

int BltRastPortTrans(struct RastPort *SrcRP ,UWORD SrcX,UWORD SrcY,struct RastPort *DestRP,
                     UWORD DestX, UWORD DestY,UWORD SizeX,UWORD SizeY)
{
int i;
UBYTE *MyArray;
UBYTE *TempArray;

if( (SizeX<1)||(SizeY<1)||(SrcX<0)||(SrcY<0)||(SrcRP==NULL) )return(0);
if( (DestX<0)||(DestY<0)||(DestRP==NULL) )return(0);

 if(MyArray=malloc((int)SizeX*(int)SizeY*3))
 {
 if(TempArray=malloc((int)SizeX*(int)SizeY*3))
 {
  ReadPixelArray(MyArray,0,0,SizeX*3,SrcRP,SrcX,SrcY,SizeX,SizeY,RECTFMT_RGB);
  ReadPixelArray(TempArray,0,0,SizeX*3,DestRP,DestX,DestY,SizeX,SizeY,RECTFMT_RGB);
  
  for(i=0;i<=SizeX*SizeY*3;i++)
   {
    //MyArray[i]=(MyArray[i]+TempArray[i])/2;
    MyArray[i]=(MyArray[i]+TempArray[i])>>1;
   }
 
  WritePixelArray(MyArray,0,0,SizeX*3,DestRP,DestX,DestY,SizeX,SizeY,RECTFMT_RGB);
 
 free(TempArray);
 }
   else{free(MyArray);return(0);
 }
 free(MyArray);
 }
 else{return(0);}
 return((int)(SizeX*SizeY));
}


Was der Code macht ist im Grunde selbstklärend. Er grabbt den Bereich des Ziel-RP, und verrechnet es mit dem Quell-RP Ausschnitt, und blittet es zurück in den Ziel-RP.
Alles Gfx-Card konform mit Sicherheits-Checks. Sicher hier und da leicht optimierbar, aber funktioniert und das nichtmal so lahm.

[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 10:22 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Das ist im groben so ähnlich wie ich es mache bei Alphatransparenz, wie im Screenshot oben.

Allerdings das hier:
MyArray[i]=(MyArray[i]+TempArray[i])>>1;

ist problematisch weil es überlaufen kann. Man müsste zuerst beide herunter Shiften oder vorher nach short oder int casten.

Es geht aber noch schneller, man kann auch gleich 4 Bytes holen, die unteren bits wegmaskieren, shiften und addieren.

Wobei aber in dem Fall das Nadelöhr das Read/Write Pixelarray ist.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 10:37 Uhr

Thore
Posts: 2266
Nutzer
> ist problematisch weil es überlaufen kann.
Ist ein Right-Shift, das hintere Bit ist in dem Fall egal ob ers verliert. Ein Overflow wird dabei nicht produziert.

> Wobei aber in dem Fall das Nadelöhr das Read/Write Pixelarray ist.
So ist es, eine Optimierung in deinem Fall macht nur wenige Takte aus, die nicht spürbar sind. Zumal Animationen mit dieser Art nicht machbar sind da der HG ja nicht selbstständig refresht wird (z.B. wenn ein Video im Hintergrund läuft). Hier müsste man den Alpha Channel der GraKa direkt ansprechen.

[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 11:59 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
> ist problematisch weil es überlaufen kann.
Ist ein Right-Shift, das hintere Bit ist in dem Fall egal ob ers verliert. Ein Overflow wird dabei nicht produziert.

Nicht der Right-Shift, sondern die vorhergehende Addition kann überlaufen, da sie in einem C-Programm wie dargestellt im Byte-Wertebereich durchgeführt wird.
Zitat:
Original von Thore:
code:
for(i=0;i<=SizeX*SizeY*3;i++)
   {
    //MyArray[i]=(MyArray[i]+TempArray[i])/2;
    MyArray[i]=(MyArray[i]+TempArray[i])>>1;
   }


Bist Du Dir sicher, dass Du die Multiplikation wirklich in jedem Schleifendurchlauf ausführen willst?
Bin ja kein Freund von exzessivem Optimieren, aber bei solch einfach vermeidbaren Dingen sollte man schon drüber nachdenken.
Zitat:
Original von Der_Wanderer:
Es geht aber noch schneller, man kann auch gleich 4 Bytes holen, die unteren bits wegmaskieren, shiften und addieren.

Das ist aber nicht dasselbe wie zuerst Addieren und dann Shiften/Dividieren.

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

[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 12:43 Uhr

Thore
Posts: 2266
Nutzer
> Bist Du Dir sicher, dass Du die Multiplikation wirklich in jedem Schleifendurchlauf ausführen willst?

Das ist schon richtig, man kann diese Multiplikation auch auslagern und das Ergebnis für die Schleife reinsetzen. In diesem WIP Stadium der Lib hab ich erstmal auf Funktionalität gesetzt. Optimierung kommt später, wenns denn nötig wird. Es sind noch Routinen drin die noch nicht 100% funktionieren, das ist vorerst wichtiger :)

Es ging hier in erster Linie ums Verständnis von Semitransparenten Bildausschnitten mittels RPA und WPA.

Auf dem 060 spürt man übrigens keinen Unterschied ob das ausgelagert ist oder nicht.

Ich nehm an es sind noch weitere kleinere Optimierungen drin (wie unter dem Source auch erwähnt) aber das soll für das Verständnis mal nicht das Augenmerk sein.

[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 17:51 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Es ging hier in erster Linie ums Verständnis von Semitransparenten Bildausschnitten mittels RPA und WPA.

Da ist die Sache mit dem Überlauf relevant...
Zitat:
Auf dem 060 spürt man übrigens keinen Unterschied ob das ausgelagert ist oder nicht.
Ja, clevere Compiler können das möglicherweise sogar selbst optimieren, aber man muss sich ja nicht darauf verlassen. Zumal man diesen Wert oftmals an anderer Stelle nochmals benötigt.

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

[ - Antworten - Zitieren - Direktlink - ]

06.01.2011, 22:25 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@Holger

Stimmt, erst Shiften und dann Addieren ist nicht das Gleiche, es geht ein Bit Genaugikeit verloren, man erhält also 21Bit Qualität statt 24bit. Wenn es aber nicht um Grafikverarbeitung geht, sondern nur um die Darstellung von z.b. Schatten etc. ist das durchaus verschmerzbar.
Es ist schon um einiges schneller, allerdings ist das ReadPixelArray der größte Broken.


Das mit der For-Schleife sollte der Optimizer eigentlich erkennen, da die Variablen Schleifeninvariant sind. Aber natürlich ist sicher immer noch sicher.

Bei guten Kompilern habe ich aber gemerkt, man sollte nicht versuchen clever zu sein, denn die Kompiler sind auf Standard Situationen optimiert.
Wenn man anfängt mit vielen Tricks zu arbeiten, "pfuscht" man dem Optimizer quasi dazwischen und es kann sogar langsamer werden.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

07.01.2011, 16:04 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Es ist schon um einiges schneller, allerdings ist das ReadPixelArray der größte Broken.

Deshalb lohnt es sich evtl. die Funktionen für den Direktzugriff auf den Grafikspeicher zu testen. Wie bereits gesagt, muss man die generische Funktion als Fall-Back behalten.
Zitat:
Das mit der For-Schleife sollte der Optimizer eigentlich erkennen, da die Variablen Schleifeninvariant sind.
Nun ja, C Compilern traue ich mittlerweile kaum mehr über den Weg. Außerdem habe ich das Gefühl, dass der durchschnittliche Programmierer gar nicht daran denkt, hinterher mit den entsprechenden -O Optionen zu übersetzen. Außerdem hört man immer wieder von Programmen, die ohne Optimierer übersetzt werden, weil sie andernfalls nicht mehr funktionieren, was auch mit den Möglichkeiten von C zu tun haben dürfte.

Und gerade bei diesem Beispiel trifft es ja zu, dass die berechneten Werte mehrfach benötigt werden.

Schreibt man:
int bitsPerRow=SizeX*3, bitsPerFrame=bitsPerRow*SizeY;

finden sich für jede Variable gleich jeweils drei Stellen um Code, die ersetzt werden könnten.
Hilft auch der Übersichtlichkeit.

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

[ - Antworten - Zitieren - Direktlink - ]

07.01.2011, 19:53 Uhr

Thore
Posts: 2266
Nutzer
> Nun ja, C Compilern traue ich mittlerweile kaum mehr über den Weg

Das war der StormC 3, der hat das recht gut gemacht.

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


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


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