4. Ein Flugzeugballerspiel - Ich brauch mal ein wenig Profihilfe

Ein Flugzeugballerspiel - Ich brauch mal ein wenig Profihilfe

  • B

    Hallo Leute, ich habe vor ein paar Wochen mit C++ angefangen und nunja, ich möchte immer sehr schnell ziemlich hoch hinaus...

    Es geht schlicht darum, dass ich momentan an einem Flugzeugballerspiel in GDI mit Borland C++ programmiere. Zwar krieg ich so an sich alles, was ich mir vornehme, hin. Es gibt allerdings eine Funktion, die ich mir selber programmiert habe, die sich extremst auf die Performance auswirkt.

    Zuerst mal das komplette Teil bisher:
    http://home.arcor.de/bigdeak/TCall678_2.zip <--- Dort müsst ihr dann "Project3.exe" öffnen!

    Ein Tipp: stellt die Windowsfarbeinstellung auf 16 Bit, sonst könnte es Fehler geben, wenn ihr in das bunte Rechteck fliegt! (ich weis noch nicht, wie man das optimiert, ist auch ersteinmal egal, ich werde hinter kommen, wenn ich es brauch ^^°).
    Ihr solltest auch, wenn ihr das gestartet habt, mal die Labels rechts im Programm lesen.

    Mein Problem: Wenn ihr das Programm jetzt startet "Project3.exe", dann werdet ihr vielleicht feststellen, dass sich dort ein buntes Rechteck befindet, wo ihr mit dem Flugzeug rein fliegen könnt - Das soll ein kleines "durchsichtiges" Rechteck sein, was auch soweit funktioniert. Mit den Tasten + und - könnt ihr die Genauigkeit der Objekte im Rechteck festlegen.
    Also die Farben im Rechteck vermischen sich mit den Farben der Objekte darin.

    Allerdings seht ihr, dass bei höchster Qualität das Spiel unspielbar wäre, weil es zu langsam ist. Ich wäre demjenigen, der mir eine Lösung bietet, "genau" das da spielbar zu machen, "ohne" OpenGL oder DirectX, sehr sehr dankbar.
    Der Quelltext ist auch dabei, den könnt ihr euch angucken, wenn ihr wollt...

    Das mit der Profihilfe hab ich gesagt, weil ich das schon ziemlich hoch einstufe, nicht jeder hat eine Vorstellung, was da für eine Technik hinter steckt...

    Ich wäre schon für eine Antwort oder eine Meinung sehr Dankbar!

    0
  • H

    wenn ich dich richtig verstehe geht es um folgendes:

    for (ff=50;ff<270;ff=ff+qual)
{
  for (cc=50;cc<190;cc=cc+qual)
  {
    Col=ColorToString(Buffer->Canvas->Pixels[ff][cc]);

    if (Col=="clWhite")
    {
      Rgb=0x00FFFFFF;
    }
    else if (Col=="clBlack")
    {
      Rgb=0x00000000;
    }
    else
    {
      Rgb=StrToInt(Col);
    }

    B=Rgb/65536%256;
    G=Rgb/256%256;
    R=Rgb%256;

    B2=0;
    G2=cc*256/240;
    R2=ff*256/320;

    B3=(B*1+B2*1)/2;
    G3=(G*1+G2*1)/2;
    R3=(R*1+R2*1)/2;

    Buffer->Canvas->Brush->Color=RGB(R3,G3,B3);
    Buffer->Canvas->FillRect(Rect(ff,cc,ff+qual,cc+qual));
  }
}

    1. mach das "ColorToString" und "StrToInt" weg!

    2. rgb-komponenten kann man ohne division und modulo extrahieren:

    b= rgb>>16&255;
g= rgb>>8&255;
r= rgb&255;

    3. wenn du schon fixpunkt-arithmetik benutzt, waehle den wertebereich so, dass die division die zweierpotenz ist:

    //G2=cc*256/240;
  G2=cc*273>>8;

    4. schreib deine farben erstmal in einen speicherblock und kopiere am ende das ganze als bitmap in dein canvas.

    0
  • B

    genau, hellihjb...

    Aber das Problem ist damit nicht gelöst!

    Übrigens, die Qualität lässt sich auf der + und - Taste "neben" dem Enter umstellen

    Denn einen Performanceunterschied ist nicht zu erkennen, indem ich das entsprechend, wie du sagtest, ändere.
    Ich würde gerne, dass es mit voller Qualität "flüssig" läuft, wie mit niedrigster Qualität...

    0
  • R
    Mod

    selbst wenn nichts gemacht werden wuerde ausser fillrect aufzurufen, duerfte das ganze gleich langsam bleiben. entweder supported die API das gewuenschte auf anderem wege (dann muss man sich mal die API reinziehen), oder es geht nicht schneller mit der API.

    0
  • B

    Ok, nun habe ich mich mal mit der ganzen Soße auseinander gesetzt, und bin auf ein recht gutes Ergebnis gekommen.
    Pixel einzeln einfach so anzusprechen soll "tödlich" für die Performance sein, es gibt eine Möglichkeit, sie über "ScanLines" anzusprechen, was ich gleich mal gemacht habe (es hat ein wenig gedauert, bis ich hinter die Technik von solchen Scanlines gekommen bin).
    Durch viel probieren und auch etwas stöbern in diesem Forum bin ich endlich auf die Verwendungsart gekommen und habe gleich mal eine neue Version erstellt mit 100% Qualität und trotzdem Spielbarkeit (und das in GDI Oo).

    Die Version ist hier zu holen:

    http://home.arcor.de/bigdeak/TCall678_3.zip

    Da auf Project4.exe klicken, übrigens geht es jetzt mit 16 Bit und 32 Bit Windowsfarben, ich bin heilefroh, dass ich die Sache hinbekommen habe (nach eine solch schnell Pixelverarbeitung suche ich schon ne Ewigkeit...)

    0
  • H
     

    Buffer->PixelFormat=pf24bit;
// ...
ptr = (Byte *)Buffer->ScanLine[ff];
for (cc=0;cc<500;cc=cc+1)
{
  ptr[cc*3+0] = ptr[cc*3+0]/2;
  ptr[cc*3+1] = (ff*256/500*1+ptr[cc*3+1]*1)/2;
  ptr[cc*3+2] = (cc*256/500*1+ptr[cc*3+2]*1)/2;
}

    du breauchtest pro pixel nur einen speicherzugriff machen wenn du ein 32bit-farbformat benutzen wuerdest, anstatt in 24bit 3 einzelne bytes auszulesen.

    ...uebrigens 5 divisionen pro pixel fuer einen farbverlauf!

    0
  • B
     

    //G2=cc*256/240;
  G2=cc*273>>8;

    hellihjb, ich merke, du hilfst mir sehr, durch diese Umstellung läuft es tatsächlich nochmal schneller, allerdings verstehe ich es nicht so ganz...
    Bitte erklär mir mal, wie man von dieses cc*256/240 auf cc*273>>8 kommt und das selbe Ergebnis erziehlt, wieso gerade 273 anstatt 240??? Ich verstehe es nicht, bitte erklär es mal (Vielleicht ist das jetzt von mir n00bhaft, aber ich habe diese Art von Berechnung wirklich noch nicht gesehen und ich merke auch, dass sich das sehr auf die Performance auswirkt, wenn ichs nicht benutze)...

    edit : Ah schon gut, bin drauf gekommen xO - big thx hellihjb ^^

    nochmal edit: Ich merke jetzt, dass auf diese Art und Weise echt alles schneller läuft, ich habe noch eine Frage... Wenn ich jetzt von Farbe 1 50% haben möchte und von Farbe 2 150% und beide miteinander vermischen möchte (Das heißt, dass das durchsichtige Objekt eine dynamische Lichtfilter hat.), müsste ich ja eigentlich folgendes machen:

    for (ff=0;ff<370;ff=ff+qual)
            {
             ptr = (int *)Buffer->ScanLine[ff];
             for (cc=0;cc<500;cc=cc+1)
               {
                Rgb = ptr[cc];
                B= Rgb>>16&255;
                G= Rgb>>8&255;
                R= Rgb&255;

                //B=((cc*131>>8)+B)/2;
                //G=((ff*177>>8)+G)/2;
                B=((cc*131>>8)*1.5+B*0.5)/2; 
                G=((ff*131>>8)*1.5+G*0.5)/2;
                //Der bunte Farbverlauf ist weniger durchsichtig

                R=G/2;
                ptr[cc] = RGB(R,G,B);

               }
            }

    Mein Problem ist jetzt eigentlich nurnoch, dass es auf diese Weise "merkbar" langsamer ist als ohne diese prozentuale Durchsichtigkeit. Ich wollte einfach fragen, ob das auch noch besser geht XD

    0
  • H

    grundlagen:
    (x>>n) macht das gleiche wie ein (deutlich aufwendigeres) x/(2^n).
    darum sollte man die werte einfach so erweitern, dass man durch zweierpotenzen dividiert, daher:

    B= cc*256/240;
 = cc*273/256;
 = cc*273>>8;

    insgesamt werden integer- und floating-point-operationen aehnlich schnell ausgefuehrt. floats muessen am ende aber wieder zu integers gerundet werden, was einige zeit in anspruch nimmt.
    man sollte auch bedenken dass divisionen durch zweier-potenzen nur in seltenen faellen vom optimizer durch den entsprechenden shift ersetzt werden.
    es macht daher sinn, alle optimierungen manuell auszufuehren.
    in deinem konkreten beispiel:

    B=( (cc*131>>8)*1.5 + B*0.5)/2;
 =( (cc*(int)(131*1.5))>>8) + (B>>1) )>>1;
 =( (cc*196>>8) + (B>>1) )>>1;
 =( (cc*196>>7) + B)>>2;

    edit: man sollte allerdings bedenken, dass die obige refaktorisierung zu leicht unterschiedlichen ergebnissen fuehrt - generell sollte man den rechts-shift moeglichst zum schluss durchfuehren um moeglichst lange in groesserer praezision zu rechnen.

    fuer genau solche farb-operationen ist eigentlich mmx erfunden worden, was dir zb alle 4 farbkomponenten gleichzeitig mit unterschiedlichen gewichtungsfaktoren multiplizieren kann.

    statische dinge wie deinen farbverlauf kann man natuerlich einfacher aus einer bitmap auslesen oder aus lineaerer interpolation erzeugen, aber es geht ja wahrscheinlich bloss um's prinzip...

    ...dass das durchsichtige Objekt eine dynamische Lichtfilter hat

    dynamisch hiesse, fuer jeden pixel eine individuelle durchsichtigkeit definieren zu koennen?
    das nennt sich alpha-blending. die staerke der transparenz (aka. alpha) kannst du dann in der vierten (unbenutzten) komponente deines 32bit-pixelformats speichern:

    // "textur" einmal am anfang generieren; normalerweise aus datei (png/tga) laden
// hier waere irgendeine geistreiche klassen-abstraktion sinnvoll:
unsigned int *texture= (unsigned int*)malloc(500*370*sizeof(int));
for (ff=0;ff<370;ff++)
{
  // zeiger auf ersten pixel der scanline:
  unsigned int *ptr = texture + ff * 500; // 500= breite einer scanline
  for (cc=0;cc<500;cc++)
  {
    int b=cc*196>>8;
    int g=ff*196>>8;
    int r=g>>1;
    // alpha-komponente pro pixel definieren:
    // hier als einfaches beispiel: linearer vertikaler verlauf
    // (erste scanline komplett durchsichtig, letzte scanline undurchsichtig)
    int a=ff*255/370;
    ptr[cc]= (a<<24)|(b<<16)|(g<<8)|r;
  }
}

    for (ff=0;ff<370;ff=ff++)
{
  unsigned int *dst = (unsigned int*)Buffer->ScanLine[ff];
  unsigned int *src = texture + ff * 500;
  for (cc=0;cc<500;cc=cc+1)
  {
    unsigned int col1= dst[cc];
    unsigned int col2= src[cc];
    int b1= col1>>16&255;
    int g1= col1>>8&255;
    int r1= col1&255;

    int alpha= col2>>24&255;
    int b2= col2>>16&255;
    int g2= col2>>8&255;
    int r2= col2&255;

    // rgb-komponenten der beiden pixel per alpha gewichten:
    r1= (r1*alpha + r2*(255-alpha)) >> 8;
    g1= (g1*alpha + g2*(255-alpha)) >> 8;
    b1= (b1*alpha + b2*(255-alpha)) >> 8;

    dst[cc] = RGB(r1,g1,b1);
  }
}

    man unterscheidet dabei zwischen "normalem" alpha-blending (siehe oben) und "pre-multiplied"-alpha:
    da der alpha-wert jedes pixels bekannt ist, kann man sich jeweils eine der zwei multiplikationen sparen, indem man die rgb-komponenten der textur bereits vorher mit dem entsprechenden alpha gewichtet.
    es bleibt:

    r1= (r1*alpha>>8) + r2;
    g1= (g1*alpha>>8) + g2;
    b1= (b1*alpha>>8) + b2;

    in diesem speziellen fall ist die zerlegung in rgb-komponenten von "src[cc]" sogar unnoetig, da bei dieser "blend-funktion" keine ueberlaeufe moeglich sind:

    unsigned int col1= dst[cc];
  unsigned int col2= src[cc];
  // alpha-blend col1:
  r1= ...
  g1= ...
  b1= ...
  col1= (r1<<16)|(g1<<8)|b;
  dst[cc]= col1 + col2;

    ;

    0
  • B

    Ok, hellhjb, das da ist jetzt sehr schwierig zu durchschauen.
    Ich werde mich noch genauer darein denken, aber ich will fragen ob ich das Prinzip richtig verstanden hab:

    Mit diesem Code, den du mir da gepostet hast, kann man aus 32 Bit Bildern praktisch den Alphaanteil noch zusätzlich auslesen und dann für jeden Pixel jeweils, wie die Alphawichtung von dem Pixel ist, auch dynamisch durchsichtig anzeigen lassen, stimmt das?

    Ich könnte also reintheopraktisch jetzt einzelne Pixel von dem Flugzeug durchsichtig machen, mit diesem Code, oder?

    0
  • H

    genau.
    probier's einfach mal aus - im zweifelsfall gibt's allerhand informationen zu "digital image compositing".
    hauptsaechlicher vorteil des alpha-channels ist, dass es nicht nur durchsichtige und undurchsichtige pixel gibt (was man auch durch color-keying erreichen koennte), sondern auch uebergaenge dazwischen, was ausserordentlich nuetzlich fuer weiche kanten (aka. anti-aliasing), und dadurch eine bessere einbettung von vorder- in hintergrund moeglich ist.
    voraussetzung ist eine zeichen-/rendering-software (photoshop, gimp) sowie ein grafik-format (png/tga/jpeg2000) das alpha-kanaele unterstuetzt.

    0
  • B

    Ich verstehe, nunja...
    Gehen wir mal davon aus, dass ich jetzt "transparente" Schüsse machen möchte...
    meinst du, es wird am Ende mit GDI noch schnell genug laufen, dass man es noch ordentlich spielen kann, schließlich geht man ja JEDEN Pixel durch, das ist doch später dann ziemlich langsam, wenn ich mehrere transparente Objekte einbauen möchte. Du hast mir auf jeden Fall sehr viel geholfen, den Code zu optimieren und es am Ende richtig flüssig zu bekommen, ohne dich hätte ich sichrlich jetzt immernoch sowas wie eine Diasshow, danke hellihjb^^

    http://home.arcor.de/bigdeak/TCall678_5.zip <--- Hier ist nun noch eine Version, dein letzter Post mit dem Alphavorschlag ist da noch nicht drin, aber ich werde mich denke mal danach richten.
    Übrigens, starte mal Project4.exe (Wegen der Gewichtung, die ich meine) und Project6.exe (Hier hab ich mithilfe dieser Sache einfach mal einen kleinen Grafischen Effekt eingebaut, was man von aktuelleren Spielen kennt :D)

    Und Anfangs dachte ich noch, dass es unmöglich sei, ohne OpenGL oder DirectX AlphaBlending zu programmieren, welches schnell genug sei...

    0

  • Im Grunde genommen ist die API egal, denn du kannst ja alles im RAM machen, und brauchst dann nur einen Call, um alles auf den Screen zu bringen. Ob das schnell genug sein kann, hängt am Ende grösstenteils von der gewählten Auflösung und Farbtiefe ab. Es gibt jedenfalls eins paar fixe Softwarerenderer auf dem Markt. f'`8k

    Autocogito

    Gruß, TGGC (\-/ has leading)

    0
  • H

    meinst du, es wird am Ende mit GDI noch schnell genug laufen, dass man es noch ordentlich spielen kann
    schließlich geht man ja JEDEN Pixel durch, das ist doch später dann ziemlich langsam

    der offensichtliche vorteil von direct3d und opengl ist natuerlich, dass das ganze rendering hardware-beschleunigt wird, waehrend du dich bei gdi (oder vergleichbaren apis wie directdraw oder sdl) auf cpu-geschwindigkeit verlassen musst.
    am besten du machst mal ein paar benchmarks, wieviele objekte du per gdi in hinreichender framerate darstellen kannst.
    nun ist gdi auch fuer gaenzlich andere anwendungen gedacht, darum sollte man noch herauszufinden, in wie weit Graphics::TBitmap::Scanline() evtl overhead kostet.

    grundsaetzlich solltest du bei deinen farboperationen immer ueberlegen ob es ueberhaupt notwenig ist, in einzelnen rgb-komponenten zu zerlegen:

    // aus unit1.h:
  Rgb1 = ptr[cc];
  Rgb2 = ptrM[cc];

  B=(B*64>>7)+(B2*192>>7)>>1;
  G=(G*64>>7)+(G2*192>>7)>>1;
  R=(R*64>>7)+(R2*192>>7)>>1;
=>
  // rgb1*0.25 + rgb2*0.75
  B=(B>>2)+(B2*192>>8);
  G=(G>>2)+(G2*192>>8);
  R=(R>>2)+(R2*192>>8);
=>
  // rgb1*0.25 + rgb2*0.5 + rgb2*0.25
  Rgb= (Rgb1>>2&0x3f3f3f) + (Rgb2>>1&0x7f7f7f) + (Rgb2>>2&0x3f3f3f);

    in diesem fall kannst du mit einem shift alle 3 rgb-komponenten "dividieren", wobei die unteren bits der "hoeheren" komponente in die oberen bits der darunterliegenden komponente verschoben werden. die kannst du einfach mit einer bitmaske entfernen in der die entsprechenden bits 0 sind.
    das ergebnis wird leicht abweichend sein weil 2x gerundet wird.

    0
  • B

    Damit wird es dann wieder schwieriger und aufwendiger, dynmaische Durchsichtigbarkeit einzubauen (Siehe Project4.exe). Ich habe das mal geändert, wie du es da vorgeschlagen hast, und zwar so:

    for (ff=0;ff<370;ff=ff+qual)
{
 ptr = (unsigned int*)Buffer->ScanLine[ff];
 ptrM =(unsigned int*)BufferM->ScanLine[ff];
 for (cc=0;cc<500;cc=cc+1)
 {
  ptr[cc]=(ptr[cc]>>1&0x7f7f7f)+(ptrM[cc]>>1&0x7f7f7f);
  //Alles in eine Zeile gekürzt
 }
}

    Auf diese Weise ist es insgesamt nochmal ein Stück schneller, ja...
    Allerdings gehts damit nur statisch, und kaum noch dynamisch, wenn du mir jetzt noch nen schnellen Vorschlag machst, wie ich die Durchsichtigkeit mit dieser Lösungsart noch dynmaischer mache, ohne großen Aufwand, wäre das sehr toll ^^

    0
  • H

    Allerdings gehts damit nur statisch, wenn du mir jetzt noch nen schnellen Vorschlag machst,
    wie ich die Durchsichtigkeit noch dynmaischer mache, wäre das sehr toll

    das:

    B=(B*64>>7)+(B2*192>>7)>>1;

    ...halte ich fuer sehr statisch 🙂
    du muesstest also erstmal spezifizieren, welche konstanten eigentlich variablen sein sollten und in welchem wertebereich sich diese bewegen.

    0
  • B

    Arf, den Wert hab ich nur statisch angegeben, aber eigentlich sollte es so gehen:

    B=(B*64>>7)+(B2*192>>7)>>1;
=>
 B=(B*(128-alpha)>>7)+(B2*(128+alpha)>>7)>>1;
    0
  • H
     

    B=(B*alpha>>7)+(B2*(255-alpha)>>7)>>1;

    um das ganze performanter zu loesen, kann man sich mmx zunutze machen.
    leider kann man den optimizer nur selten dazu ueberreden, solche konstruktionen selbststaendig zu erzeugen.
    und weil mir gerade langweilig war 😉 zeige ich mal wie das aussehen koennte:

    void alphaBlendScanline(unsigned int *dst, unsigned int *src, int alpha, int len)
{
   if (alpha<0) return; // komplett durchsichtig: es gibt nichts zu tun
   if (alpha>255) alpha=255; // evtl spezialfall-behandlung: komplett undurchsichtig -> kein blending
   unsigned int a1= alpha * 0x01010101; // = (alpha<<24)|(alpha<<16)|(alpha<<8)|(alpha);
   unsigned int a2= ~a1; // 255-alpha in jeder komponente

   _asm {
      mov       edi,dst   // addresse dst
      mov       esi,src   // addresse src
      mov       ecx,len   // loop-counter

      pxor      mm7,mm7   // 0

      movd      mm2,a1    // 32bit alpha in 64bit-mmx-register laden: 0|0|0|0|a|a|a|a (8x8bit)
      punpcklbw mm2,mm7   // 8x8bit in 4x16bit mit 0 erweitern: 0|0|0|0|a|a|a|a -> 0.a|0.a|0.a|0.a

      movd      mm3,a2    // 255-alpha: 0|0|0|0|a|a|a|a
      punpcklbw mm3,mm7   //  0.a|0.a|0.a|0.a

   blendloop:
      movd      mm0,[edi] // mm0= *dst => 32bit farbe in 64bit-mmx-register lesen: 0|0|0|0|a|r|g|b (8x8bit)
      punpcklbw mm0, mm7  // 8x8bit in 4x16bit erweitern: mm0= 0.a|0.r|0.g|0.b
      pmullw    mm0, mm3  // 4x 16bit multiply: mm0= a*a2|r*a2|g*a2|b*a2

      movd      mm1,[esi] // das gleiche nochmal mit src[0]
      punpcklbw mm1, mm7  
      pmullw    mm1, mm2  // multiply mit a1

      paddusw   mm0, mm1  // mm0 += mm1 => 4x 16bit addition: a1+a2|r1+r2|g1+g2|b1+b2
      psrlw     mm0, 8    // mm0= 0.a|0.r|0.g|0.b (4x >>8)
      packuswb  mm0, mm7  // mm0= 0|0|0|0|a|r|g|b (8x8bit)

      movd      [edi], mm0 // *dst= mm0  32bit-farbe schreiben
      add       edi,4      // dst++
      add       esi,4      // src++
      dec       ecx        // len--
      jnz       blendloop  // while (len>0)
      emms                 // mmx-ende: fpu-register wieder herstellen
   };
}

    for (ff=0;ff<370;ff=ff+qual)
{
 ptr = (unsigned int*)Buffer->ScanLine[ff];
 ptrM =(unsigned int*)BufferM->ScanLine[ff];
 alphaBlendScanline(ptr, ptrM, alpha, 500);
}

    ...was hier passiert:
    mmx bietet 64bit register und die moeglichkeit in einem taktzyklus 4 16bit-zahlen (die "nebeneinander" in ein register passen) parallel zu multiplizieren.
    zu diesem zwecke liesst man also eine 32bit farbe im format 4x8bit a|r|g|b (oder andersrum; is auch egal) in ein (64bit-)mmx register.
    dabei bleiben die oberen 32bit unbenutzt: 8x8bit x|x|x|x|a|r|g|b
    das erweitert man so, dass 4 16bit-komponenten entstehen: 0|a| 0|r| 0|g| 0|b
    warum? weil mmx nur 16bit-komponenten multiplizieren kann; klingt komisch - is' aber so.
    gleichzeitig bringt man die transparenz-konstante in das gleiche format: 0|a| 0|a| 0|a| 0|a
    und multipliziert die beiden mmx-register; wir erhalten also 4 16bit-komponenten in denen jeweils 2 bytes multipliziert sind.
    durch paralleles shiften fallen jeweils die unteren 8bit jeder komponente wieder raus und das ganze kann wieder zurueck ins 32bit-pixelformat konvertiert werden.

    oversized. aber 3x schneller 😉

    0
  • B

    uff, das ist assembler, ach du dicke Kanone, ich werde die Funktion mal verwenden, ich editiere dann mal hier rein, was ich davon halte ^^

    Unfassbar, es funktioniert, ich danke dir nochmals...
    ich werde diese Funktion nutzen, wenn du nichts dagegen hast, ich habe zwar noch kein Plan von Assembler, aber das scheint echt mal gut zu sein.
    Es läuft jetzt recht schnell, vielen Dank ^^

    Es wäre jetzt noch toll, wenn du mir diese Assembler Funktion so erweitern könntest, dass man das mit diesen 32 Bit Bildern machen kann und da für jeden Pixel das Alpha ausließt, das wäre sehr schön ^^

    Zusätzlich könntest du noch einfügen, dass man den Bereich auf dem Bildschirm, wo das Bild angezeigt wird, auch selber als Parameter übergeben kann (Zwar kann man die Y Position locker einstellen, aber... die X Position ist immer ganz links bis zum Bereich, den man als letzten Parameter der Funktion übergibt) XD

    Übrigens, ich habe dich mal im MSN Messenger geaddet, wäre nett, wenn du da mal online kämst, dann könntest du mir direkter helfen ^^

    0
  • H

    jaja, gibt man den kleinen finger... 😉
    - aber so langweilig ist mir nun auch wieder nicht :p

    wenn du mir diese Funktion so erweitern könntest, dass man für jeden Pixel das Alpha ausließt

    es wird dich aber nicht weiterbringen, wenn du es nicht selbst versuchst...

    dass man den Bereich wo das Bild angezeigt wird als Parameter übergeben kann

    das kannst du leicht selber machen in dem du als ziel-pointer (dst) jeweils die entsprechende scanline plus horizontaler pixelposition uebergibst.

    0

  • Bigdeak schrieb:

    Übrigens, ich habe dich mal im MSN Messenger geaddet, wäre nett, wenn du da mal online kämst, dann könntest du mir direkter helfen ^^

    *invisible aktivier* 😎

    Gruß, TGGC (\-/ has leading)

    0
Anmelden zum Antworten