[DynRPG Plugin]Blending Mode

[Kazesui]

"Sollte" nicht, kann aber sein. Habe nicht wirklich solch grossen Bilder ausprobiert.
Ich werde mal daran schauen

[Kazesui]

Jupp, gab ein Bug dabei @große Bilder.
Sollte jetzt behoben sein

[Corti]

Hrm, leider kein Quellcode dabei :-(

[Kazesui]

Hrm, leider kein Quellcode dabei :-(

...

Source
Hoffentlich jetzt auch noch bugfrei

[Kyuu]

Mir ist beim Überfliegen aufgefallen, dass du die Arrays im Destruktor nicht korrekt deallozierst:

Code:

    ~ImageData()
    {
        delete r;
        delete g;
        delete b;
    }

Korrekt wäre:

Code:

    ~ImageData()
    {
        delete[] r;
        delete[] g;
        delete[] b;
    }

[Cherry]

Code:

RPG::variables[7] = scriptLine->parameter(0);

Wohl noch Debug-Code. Gehört dringend raus.

Außerdem würd ich auch noch ein onInitTitleScreen machen und da die Blends löschen. Pictures können ja auch durch das Starten/Laden eines Spiels gelöscht werden!

Und der von Kyuu angesprochene Bug gehört auch dringend gefixt da der ein Memory Leak verursacht, soweit ich weiß.

Ach, Kazesui, Anregung: Ein Plugin um direkt 16-Bit-Bilder anzuzeigen! (Müsstest du dann halt selber laden, mit einer PNG-Lade-Bibliothek)

[Kazesui]

Danke, gehört raus ja, und stimmt auch noch @Starten/Laden. Habe diesmal schon einiges vergessen, mist.
Sollte natürlich auch

Code:

delete[]

sein. Ist glaub ich compiler bedingt in genau diesem Fall (Habe kein leak entdeckt als ein paar tausend mal pictures erstellen und löschen lies), sollte aber trotzdem natürlich drin sein, weil man sich auf sowas nicht verlassen soll. Danke.

Werde ich wohl zu meiner Liste hinfügen müssen @16-Bit-Bilder.

[Kyuu]

Ist glaub ich compiler bedingt in genau diesem Fall (Habe kein leak entdeckt als ein paar tausend mal pictures erstellen und löschen lies), sollte aber trotzdem natürlich drin sein, weil man sich auf sowas nicht verlassen soll.

...

Bei primitiven Datentypen wird der Speicher zwar offenbar auch mit delete freigegeben, aber - wie du selbst bemerkt hast - ist das alles andere als verlässlich und um genau zu sein sogar undefiniertes Verhalten.

Spätestens sobald du Klassen mit RAII hast, d.h. allozierter Speicher wird in den Destruktoren wieder freigegeben, bekommst du einen Memory Leak, weil die Destruktoren nur mit delete[] aufgerufen werden.

Problematisch kann es auch bei Operatorüberladung werden: http://www.parashift.com/c%2B%2B-faq...built-ins.html

[Corti]

Moin.

Einfrieren bei Erase Picture. Doch kein Phänomen des Picture Pointer Patches.

Code:

bool onEventCommand(RPG::EventScriptLine *scriptLine, RPG::EventScriptData *scriptData, int eventId, int pageId, int lineId, int *nextLineId)
{
    if(scriptLine->command == RPG::EVCMD_ERASE_PICTURE)
    {
        Blend::iterator itr = blends.find(scriptLine->parameter(0));
        if(itr != blends.end())
        {
            delete itr->second;
            blends.erase(itr);
        }
        Active::iterator tmp = active.find(scriptLine->parameter(0));
        active.erase(tmp);
    }
    if(scriptLine->command == RPG::EVCMD_SHOW_PICTURE)
    {
        Blend::iterator itr = blends.find(scriptLine->parameter(0));
        if(itr != blends.end())
        {
            delete itr->second;
            blends.erase(itr);
        }
        Active::iterator tmp = active.find(scriptLine->parameter(0));
        if(tmp != active.end())
            active.erase(tmp);
    }
    return true;
}

Haha, Quiz: Wie hab ich das hier gemacht? ^^



Lösung:

• Normales Bild ( 0% Transparenz ) auf id 14
• fyr.add.png auf id 15

Tipps:

• Wichtig sind nicht die ids, sondern das add-Bild im Script nach dem anderen anzuzeigen

[Corti]

News update:
Das Phänomen komischer Bildanzeigen hab ich in meiner Adaption des Scriptes gelöst.

Code (Aus dem Sourcecode, den du mal veröffentlicht hast: ):

 
bool onDrawPicture(RPG::Picture* picture)
{
 ( ... ) 
 
        char* filename = picture->filename;
        std::string type;
        int i = -1;
        while(filename[++i] != '.'); // <--- Knackpunkt hier 
        int n = ++i + 3;
        for(; i < n; ++i)
            type += filename[i];
        if(!type.compare("add"))
        {
            active[id] = 1;
            blends[id] = new ImageData(picture);
            drawAdditive(id);
            return true;
        }
( ... )
 

Dateinamen enden zumindest bei mir nicht mit ".png" sondern enthalten gar keinen Punkt wenn kein ".add" oder Ähnliches vorhanden ist. Der Screenshot oben kommt zustande wenn bei einem "non-blend"-Picture, ausserhalb des Bereiches des Dateinamens irgendwo ein Punkt gefolgt von gültigen drei Zeichen gefunden wird zB auf Index 15466 bei mir ;-)

[Kazesui]

Danke! Ich hab tatsächlich nicht gemerkt daß der .png bei RPG::Picture::filename nicht dabei ist.
Dieser Bug sollte nun behoben sein + es ist jetzt auch möglich mit der Transparenz rumzuspielen bei dem Blend Bilder.

neuer source code

[Corti]

Hey Kazesui,

ich hab in meiner Variante unter anderem Softlight eingebaut, bin mir aber noch nicht ganz sicher ob ich dabei nicht einen Fehler gemacht habe.
(Siehe Programmierforum : http://www.multimediaxis.de/threads/...73#post3061073 )

Das Topic ist nach meinen Edits reichlich konfus, ich bitte das zu entschuldigen. Wäre cool wenn du mal drauf schauen könntest. Wenn es dir zusagt kannst du das Codestück auch gerne übernehmen, hab den Grundcode schliesslich auch durch dich.
Softlight hat bei mir das Kürzel "sfl"

r = (src >> 11) > imgData->r[iPtr] ? (src >> 11) : imgData->r[iPtr];
g = ((src & 0x07E0) >> 5) > imgData->g[iPtr] ? ((src & 0x07E0) >> 5) : imgData->g[iPtr];
b = (src & 0x001F) > imgData->b[iPtr] ? (src & 0x001F) : imgData->b[iPtr];

r = (src >> 11) < imgData->r[iPtr] ? (src >> 11) : imgData->r[iPtr];
g = ((src & 0x07E0) >> 5) < imgData->g[iPtr] ? ((src & 0x07E0) >> 5) : imgData->g[iPtr];
b = (src & 0x001F) < imgData->b[iPtr] ? (src & 0x001F) : imgData->b[iPtr];