[Dowolny] Battle transition

[marekssj2]

Witam mam dość nietypowe pytanie. Jak działa (mechanicznie) przejście przed walką z przeciwnikiem?
CHodzi mi tu o ten dziwny efekt gry rozpoczyna się walka.
Mi się wydaje że działa to na zasadzie zmniejszania alphy obrazka, jednak nie znam się za bardzo i chciał bym się upewnić. A najlepiej by było gdyby ktoś podał fragment kodu odpowiedzialny za te "czary". ;-)

[AlmostNoRuby]

Wyłączyłem przez przypadek okno z odpowiedzą
Dobra: po pierwsze, fragment kodu odpowiedzialny za przejście (ang. transition) jest ukryty w klasie Graphics, która sama jest ukryta. W pliku *.dll gry.
Jedyne, co oficjalnie jest podawane, to:

Spoiler: (Otwórz)

Graphics.transition([duration[, filename[, vague]]])
Carries out a transition from the screen fixed in Graphics.freeze to the current screen.

duration is the number of frames the transition will last. When omitted, this value is set to 8.

filename specifies the transition graphic file name. When not specified, a standard fade will be used. Also automatically searches files included in RGSS-RTP and encrypted archives. File extensions may be omitted.

vague sets the ambiguity of the borderline between the graphic's starting and ending points. The larger the value, the greater the ambiguity. When omitted, this value is set to 40.

Po rozpakowaniu biblioteki (mi się nie udało, udało się temu gościowi [link]), możesz znaleźć taki fragment kodu w C++:

Spoiler: (Otwórz)

Kod: (Zaznacz wszystko)

void Graphics::transition(int duration,
                          const char *filename,
                          int vague)
{
    p->checkSyncLock();

    if (!p->frozen)
        return;

    vague = clamp(vague, 1, 256);
    Bitmap *transMap = *filename ? new Bitmap(filename) : 0;

    setBrightness(255);

    /* Capture new scene */
    p->compositeToBuffer(p->currentScene);

    /* If no transition bitmap is provided,
     * we can use a simplified shader */
    TransShader &transShader = shState->shaders().trans;
    SimpleTransShader &simpleShader = shState->shaders().simpleTrans;

    if (transMap)
    {
        TransShader &shader = transShader;
        shader.bind();
        shader.applyViewportProj();
        shader.setFrozenScene(p->frozenScene.tex);
        shader.setCurrentScene(p->currentScene.tex);
        shader.setTransMap(transMap->getGLTypes().tex);
        shader.setVague(vague / 256.0f);
        shader.setTexSize(p->scRes);
    }
    else
    {
        SimpleTransShader &shader = simpleShader;
        shader.bind();
        shader.applyViewportProj();
        shader.setFrozenScene(p->frozenScene.tex);
        shader.setCurrentScene(p->currentScene.tex);
        shader.setTexSize(p->scRes);
    }

    glState.blend.pushSet(false);

    for (int i = 0; i < duration; ++i)
    {
        /* We need to clean up transMap properly before
         * a possible longjmp, so we manually test for
         * shutdown/reset here */
        if (p->threadData->rqTerm)
        {
            glState.blend.pop();
            delete transMap;
            p->shutdown();
            return;
        }

        if (p->threadData->rqReset)
        {
            glState.blend.pop();
            delete transMap;
            scriptBinding->reset();
            return;
        }

        p->checkSyncLock();

        const float prog = i * (1.0f / duration);

        if (transMap)
        {
            transShader.bind();
            transShader.setProg(prog);
        }
        else
        {
            simpleShader.bind();
            simpleShader.setProg(prog);
        }

        /* Draw the composed frame to a buffer first
         * (we need this because we're skipping PingPong) */
        FBO::bind(p->transBuffer.fbo);
        FBO::clear();
        p->screenQuad.draw();

        p->checkResize();

        /* Then blit it flipped and scaled to the screen */
        FBO::unbind();
        FBO::clear();

        GLMeta::blitBeginScreen(Vec2i(p->winSize));
        GLMeta::blitSource(p->transBuffer);
        p->metaBlitBufferFlippedScaled();
        GLMeta::blitEnd();

        p->swapGLBuffer();
    }

    glState.blend.pop();

    delete transMap;

    p->frozen = false;
}

albo

Spoiler: (Otwórz)

Kod: (Zaznacz wszystko)

MRB_FUNCTION(graphicsTransition)
{
    mrb_int duration = 8;
    const char *filename = "";
    mrb_int vague = 40;

    mrb_get_args(mrb, "|izi", &duration, &filename, &vague);

    GUARD_EXC( shState->graphics().transition(duration, filename, vague); )

    return mrb_nil_value();
}

Więc to mamy za sobą. Sprawa 2:

1. Nowy projekt
2. Wklej obrazek transition (przejścia) do folderu Picture.
3. Ustaw w projekcie parę zdarzeń, które mają za zadanie ustawić obrazek i go przeobrażać (pozytyw/ negatyw/ kolorystyka/ przyciemnienie ekranu itd.)
4. Może dojdziesz
   

[Mateusz SSJ8]

Przepraszam za odkop, ale AlmostNoRuby jest w błędzie.

Grafiki przejścia nie wrzuca się do folderu "pictures". W RPG Makerze XP ich miejsce jest w folderze "transitions". Tu właśnie popełnił błąd.

W nowszym RPG Makerze, niż XP jest tylko jedna czarno-biała grafika (zaraz powiem, dlaczego). Znajdziesz ją w folderze "system" i odpowiada ona za przejście do walki.

Ze wszystkich RPG Makerów korzystających z RGSS jedynie RPG Maker XP obsługuje przejścia na zawołanie. Polecenia zdarzenia odpowiedzialne za to mają kody 211 (przygotowanie) i 212 (wykonanie, wybierz). Grafiki przejścia muszą być w odcieniach szarości.

[AlmostNoRuby]

Czy wpiszesz Cache.transitions("plik") czy Cache.pictures("plik") w poleceniu Graphics.transition(60, Cache...) to chyba nie ma różnicy.

[Mateusz SSJ8]

No, właśnie różnica jest. Polecenie wykonania przejścia RPG Makera XP liczy tylko pliki znajdujące się w "graphics/transitions", a funkcje, które to egzekwują, nie korzystają z modułu "Cache". Z resztą ile razy na raz można wywołać jedno przejście. Trzeba byłoby po nim zwalniać pamięć modułu.

[AlmostNoRuby]

Dobra. Po prostu zajrzyj do funkcji perform_graphics_transitions w Scene_Map (chyba)