Programmwunsch und -erstellungsthread #2

[Kazesui]

Die qualität der Bilder selber wurde etwas schlechter da die nicht gleich "2k3" kompatibel waren und ich nicht viel zeit vergeuden wollte indem ich versuchte den Qualität von denen zu behalten.
Das hier zeigt aber was maker gebautes, ja, bzw. mit DynRPG SDK. Nicht sonderlich sophistikiert, nur ein "OR" zwischen die Pixeln der Flammen und dem hintergrund (sieht also ziemlich schrecklich aus an helleren Hintergründe).

[MagicMaker]

Das hab ich irgendwie erwartet, wenn Kazesui hier postet.
Mit einer Bereitstellung von Dyn für RPG2000 wären jetzt alle Probleme gelöst, denn auf 2003 funktioniert
das Spiel schon vom technischen Aufbau her nicht.

Gibt es eigentlich noch anderes als OR, was brauchbare Ergebnisse hervorbringt?

[Kazesui]

Bestimmt. Wird aber meiner wissen nach dann auch schnell um einiges komplizierter. Da müsste ich es wahrscheinlich etwas näher studieren.

[Kyuu]

Kazesui: In welchem Format sind die Quell- und Ziel-Pixel?

Wenn beide im R5G6B5-Format sind, wäre die korrekte Implementierung des additiven Blendings:

Code:

unsigned short src = ...;
unsigned short dst = ...;

unsigned char r = std::min(31, (dst >> 11) + (src >> 11));
unsigned char g = std::min(63, ((dst & 0x07E0) >> 5) + ((src & 0x07E0) >> 5));
unsigned char b = std::min(31, (dst & 0x001F) + (src & 0x001F));

unsigned short result = (r << 11) | (g << 5) | b;

Wenn nicht und du mir das Format beider Pixel nennen kannst, kann ich dir den korrekten Code für additives oder subtraktives Blending liefern.

[Kazesui]

Die sind beide schon in R5G6B5 Format, und die von dir gebene implementierung funktioniert schon um welten besser. Bleibt nur für mich rauszufinden wo ich bei meinem additiven algorithmus falsch ging

Code:

uint16_t src = ...;
uint16_t dst = ...;

uint16_t tmp = (src | dst) & 0x8410;

src &= 0x7BEF;
dst &= 0x7BEF;

uint16_t result = (src + dst) | tmp;

Erscheint mir im Prinzip das gleiche zu tun, gibt wohl aber irgendein Denkfehler drin. Da werde ich wohl später es genauer ansehen müssen.

[Kyuu]

Die Byte-Reihenfolge sollte nicht das Problem sein, da du nicht explizit auf einzelne Bytes zugreifst. Ich glaube das Problem bei diesem Code ist, dass die Sättigung nicht funktioniert. Ist etwas schwierig nachzuvollziehen was genau du dir dabei gedacht hast.

[Kazesui]

Die gedanke wars der höchste Bit beim jedem Farbe raus zu maskieren damit es keine overflows bis in die anderen farben ginge sobald ich die beiden farben zusammen gelegt habe, und dannach das höchste bit wieder reinzu tun. Sehe jetzt aber das es bei so einem overflow doch schlimm geht weil dann sollten die ganzen bits ja einfach 1 sein, und nicht mehr oder weniger zufällig wie bei mir da oben.

[Kyuu]

Ich nehme an, der Grund dafür war die conditional branches zu eliminieren? In dem Fall würden sich SSE2 intrinsics anbieten, also im Besonderen __m128i _mm_adds_epu8. Erfordert dann etwas mehr Vorbereitung, d.h. die Farbkomponenten müssen entpackt, hochskaliert und später wieder runterskaliert und gepackt werden, dafür werden die conditional branches komplett eliminiert und 4-5 Pixel können mit einer einzigen Operation verarbeitet werden. Wenn du möchtest, kann ich dir später eine Beispiel-Implementierung zeigen. Ob das dann auch tatsächlich schneller wäre, müsste man genau testen.

[Kazesui]

Der eigentliche grund war dass ich es ziemlich spät geschrieben habe und habe schnell gedacht dass vielleicht ginge es direkt die farbe zu addieren ohne die verschiedne Komponente erst mal zu separieren. Zu der zeit fiel es mir nicht ein dass ich ja noch n Branch brauchen wurde um die Komponente an ihrem max werte zu halten, und denkte nur daran zu verhindern dass ein bit von der eine Komponent in das andere fließen wurde.

Ich wurde aber sehr gern ein beispiel davon sehen wie man sowas mit simd machen kann. Auch wenn es hier vielleicht nicht schneller wäre könnte es für spätere fälle noch nützlich sein.


@wer sonst noch mitliest, so sieht es aus mit dem richtigen Additiven Blending von Kyuu

[Rosa Canina]

Oh.... my... God.

Das ist jetzt mit DynRPG gemacht, wenn ich das richtig verstanden habe... oder?
Das würde bedeuten... ich muss das unbedingt noch irgendwie in AVoR reinbekommen O_______O

Super Arbeit, ganz tollig

[Kyuu]

Der eigentliche grund war dass ich es ziemlich spät geschrieben habe und habe schnell gedacht dass vielleicht ginge es direkt die farbe zu addieren ohne die verschiedne Komponente erst mal zu separieren. Zu der zeit fiel es mir nicht ein dass ich ja noch n Branch brauchen wurde um die Komponente an ihrem max werte zu halten, und denkte nur daran zu verhindern dass ein bit von der eine Komponent in das andere fließen wurde.

...

Achso, ich habe sowas Ähnliches bis jetzt nur im Zusammenhang gesehen, wenn versucht wurde die branches zu eliminieren.

BTW, wenn du schon dabei bist kannst du auch gleich subtraktives Blending implementieren (wenn du es noch nicht getan hast). Ich bin mir sicher die Leute würden sich darüber nicht weniger freuen, vor allem da eine Kombination aus additivem und subtraktivem Blending eine Art dynamische Belichtung ermöglicht. Der Code für subtraktives Blending entspricht in etwa dem Code für additives Blending mit ein paar Ausnahmen:

Code:

unsigned short src = ...;
unsigned short dst = ...;

unsigned char r = std::max(0, (dst >> 11) - (src >> 11));
unsigned char g = std::max(0, ((dst & 0x07E0) >> 5) - ((src & 0x07E0) >> 5));
unsigned char b = std::max(0, (dst & 0x001F) - (src & 0x001F));

unsigned short result = (r << 11) | (g << 5) | b;

Ich wurde aber sehr gern ein beispiel davon sehen wie man sowas mit simd machen kann. Auch wenn es hier vielleicht nicht schneller wäre könnte es für spätere fälle noch nützlich sein.

...

Ok, ich schicke dir dann später eine PM.

[MagicMaker]

Oh me likes. Aber du musst nicht meinen Screen in abschreckender Farbreduzierung dafür nutzen,
etwas eigenes würde auch zur Demonstration gehen. ^-^

Und noch immer stellt sich mir da in den Weg, dass das mit meinem Spiel so auf Dyn nicht kompatibel ist.

Man müsste sowieso nochmal anders programmieren, denn ich nutze eine XRGB-Modifikation aus dem
DestinyV2-Patcher, um mehr als 16bit auf dem Spielbildschirm zu haben, da würde eine Verrechnung mit
R5G6B5 sicher zu einem seltsamen Ergebnis führen.

[Kazesui]

Tut mir leid @demo, hab ich jetzt schnell mal geändert.

[MagicMaker]

Das kommt ja gleich viel cooler zur Geltung. =D

[Corti]

Mich würd der Sourcecode ja mal ganz stark interesssieren =0

[Kazesui]

Das von da oben ist eher ein Prototyp als was brauchbares zur zeit (bzw. so ziemlich für das Flammenbild ausgelegt).
Die interessanten Linien der source gibts schon im Code beispiele da oben + ein paar die dem pixels holen.
Ein RPG::Image ladet ein bild hoch, und die farben werden per RPG::Image:ixels geholt und dann mit dem von das entsprechende pixel des RPG::screen->canvas kombiniert (durch dem scanline Methode).
Sprich:

Code:

RPG::Image* image;
...
uint16_t* pixels = image->pixels;
uint16_t* scanline = RPG::screen->canvas->getScanline(y)
...
uint16_t src = scanline[x];
uint16_t dst = RPG::Canvas::convert24To16Bit(image->palette[pixels[img_index]]);
... // und dann das addieren von da oben
scanline[x] = (r << 11) | (g << 5) | b;

Der richtige Sourcecode kommt erst wenn ich es fertig habe, oder zumindest viel näher dran bin es fertig zu machen. Was für ein lösung ich verwenden werde ist sowieso noch nicht gewiss

[Cherry]

Du könntest ja Pictures erlauben die additives/subtraktives Blending nutzen, indem du onDrawPicture behandelst. Zeugs wie Rotation und Ripple funktionieren dann zwar wahrscheinlich nicht, Zoom wird im Moment auch eher noch zu viel Aufwand sein, aber vom Prinzip her müsste es schon mal viel bringen! (Man könnte ja z.B. nachkucken ob der Dateiname ".add." bzw. ".sub." enthält, wie in "meintest.add.png" und das als Merkmal zur Blendingentscheidung nehmen.)

Kuck dir dazu aber noch http://rpg-maker.cherrytree.at/dynrp...e.html#details genauer an. Du könntest das dort angesprochene Zwei-Hälften-Problem so lösen:

Code:

if(picture->image->palette[0] == picture->image2->palette[0]) {
    // Picture wurde noch nicht zusammengeführt, also machen wir es jetzt
    picture->merge();
    // Markierung dass das Bild zusammengeführt wurde
    // Normalerweise sollte man immer RPG::Image::setPalette verwenden, aber hier ist es egal weil image2 ja jetzt eh leer ist
    picture->image2->palette[0] = ~picture->image->palette[0];
}

Übrigens:

If you loop through rows, it is way faster to use getScanline(0) once and then always add lineSize to get to the next row instead of calling getScanline for every row.

...

[MagicMaker]

~~ Ich weiss nicht ganz wohin hiermit, also... mal sehen.


Kann es sein, dass ich eventuell leicht plemplem bin, sowas zusammenzuhexen?

[MagicMaker]

↑↑↑
Das ist jetzt aktuell draus geworden.


Yeay, ein grosses Breitbildchen.


Naja... nicht überall, ich müsste erstmal wissen, wie gross die Mapanzeige im 320x240-Original wirklich ist.


Halbwegs erfreulich, der da funktioniert auch.

[BlueGesyr]

Darf ich auch wünsche äußern, ohne die vorigen 73 Seiten vollständig gelesen zu haben?

Im Prinzip gibt es 3 Programm(-e/-Erweiterungen/-Features), die ich mir wünschen würde:
1. Variabel- und Switchlisten exportieren und importieren, um die Namen außerhalb des Makers bearbeiten zu können. (Eventuell als Feature des "RPG Maker 2009 Ultimate"? )
2. Ein komfortableres Resourcenverwaltungstool im "RPG Maker 2009 Ultimate". D.h. Multiimport/-export, leichtere Ordnerverwaltung oder Import direkt in den Ordner.
3. Eine Erweiterung der "RMEventFactory", so dass man in "Value to replace" auch Formeln angeben und mehr als 8 Replace-Werte gleichzeitig anwenden kann. Zudem wäre im Zusammenspiel mit commentbasierten Skriptsprachen die Option schön, auch Werte innerhalb Comments ändern zu können.

Ich hoffe, diese Wünsche wurden noch nicht genannt/abgelehnt bzw. sind Thema ausgenommen.