Programmwunsch und -erstellungsthread #2

[Cherry]

Chili hat einen Bug gefunden:

Ich habe es geschaft den Absturz zu reproduzieren und noch ein Mysterium (jedenfalls für mich ) aufzudecken. Wenn auch nicht zu lösen.
Der Absturz kommt, wenn ich im Kampf in das Itemmenü gehe aber nichts benutze sondern via Abbruchtaste wieder zurück gehe und dann den Nachladen Befehl nutze.
Das Skript wird ausgeführt, aber sofort danach kommt die Fehlermeldung und das Spiel stürzt ab.

Zum anderen Mysterium:
Anders verhält es sich wenn ich ein Item benutze und im darauffolgenden Zug in das Itemmenü gehe, wieder raus gehe und dann nachladen benutze. Dann wird das
Nachladen Skript und Animation ausgeführt, aber das Item was im vorrigen Zug benutzt wurde, wird wieder verwendet gleich nach dem Nachladen.
Das Gleiche passiert mit dem Skillmenü im Kampf. Nur dass wenn ich keinen Skill benutze nichts abstürzt. Sondern falls ein Skill in der letzten Runde benutzt wurde,
ich im nächsten in das Skill Menü gehe, die Abbruch Taste drücke, dann nachladen benutze, dann wird der Skill aus dem letzten Zug nach dem Nachladen ausgeführt.

Wenn ich Humor hätte, würde ich das jetzt als Feature verkaufen. Sozusagen als Bonusaktion, fürs nachladen...
Das alles gilt übrigens für den Aktiven und Passiven Modus des Kampfsystems.

...

Dies ist tatsächlich ein sehr ärgerlicher Bug im RM2k3. Ich habe diesen Bug gleich gefixt.

Fixed.

http://share.cherrytree.at/showfile-...ventbugfix.ips
Lade Lunar IPS herunter, klicke Apply IPS Patch, wähle die IPS-Datei die ich verlinkt habe, dann wähle im nächsten Fenster unten Alle Dateien und such deine RPG_RT.exe raus. WICHTIG: Nur auf RPG_RT Version 1.08 anwenden! (Ja, Chili, deine ist so eine.)

Ich werd den Bugfix auch in die nächste DynRPG-Version einbauen.

Hier noch die technische Erklärung - wer DynRPG-Entwickler ist, versteht sie:
Der RPG Maker setzt den Member "kind" der RPG::Action eines RPG::Battler's auf RPG::AK_NONE wenn sein Zug beendet ist.
Der RPG Maker setzt den Member "kind" der RPG::Action eines RPG::Battler's auf RPG::AK_SKILL bzw. RPG::AK_ITEM wenn er einen Skill- oder Item-Befehl wählt.
Der RPG Maker setzt den Member "skillId" bzw. "itemId" der RPG::Action eines RPG::Battler's dann, wenn er den Skill/das Item ausgewählt und aktiviert hat.
Der RPG Maker ändert an der RPG::Action gar nichts, wenn ein "Link to Event" Befehl aktiviert wird.

Und da liegt auch der Bug begraben: Wenn der Spieler ein Skill-/Itemmenü öffnet, wird die Action verändert (RPG::AK_SKILL bzw. RPG::AK_ITEM), aber wenn er das Menü mit Escape wieder verlässt ohne den Skill/das Item wirklich zu aktivieren, wird an der Action nichts mehr geändert! Bei einem "Link to Event"-Befehl wird dann auch nichts mehr geändert, d.h. es steht noch immer beispielsweise RPG::AK_ITEM drin! Der "skillId" bzw. "itemId" Wert wird erst bei der tatsächlichen Auswahl des Skills/Items gesetzt, d.h. in diesem Fall steht noch dasselbe drin wie beim letzten Zug. Pech nur, wenn vorher z.B. überhaupt noch kein Item von diesem Helden aktiviert wurde, dann steht da als "itemId" nämlich noch 0 drin. Der RPG Maker führt nun die Action aus und versucht, Item #0 zu aktivieren => Bääm, Absturz.

Dasselbe Problem dürfte übrigens auch mit "Row" (statt mit einem "Link to Event"-Befehl) vorkommen, dieser Befehl ändert die Aktion nämlich auch nicht.

Mein Bugfix macht einfach folgendes: Wenn ein Befehl aktiviert wurde, der nicht "Attack", "Skill", Skill Subset", "Item", "Defend" oder "Escape" ist (diese Befehle ändern die Action nämlich), dann wird der RPG::Action::kind Member nochmal explizit auf RPG::AK_NONE gesetzt.

...

mfG Cherry

[Corti]

Nice!

[Cherry]

Durch einen Tippfehler wurde dafür jetzt IMMER der letzte Skill ausgeführt. Bäh.

Bitte nochmal patchen.

[MagicMaker]

Ich wär der erstbesten Person noch immer sehr verbunden, die mir das ermöglicht:

[MajinSonic]

Ist das ein 2k3 Spiel?
Alphachannel wäre wirklich geil...

[MagicMaker]

Das ist weder 2003 noch Alpha. ^-^

Wenn du dich mit befassen willst, les was über Blending.

[MagicMaker]

Weil ich so nett bin, noch eine Veranschaulichung des Unterschieds zu einem einfachen Alphakanal (rechts),
schnell im Grafikprogramm zusammengebastelt.

[MarcL]

Das ist weder 2003 noch Alpha. ^-^

Weil ich so nett bin, noch eine Veranschaulichung des Unterschieds zu einem einfachen Alphakanal (rechts),
schnell im Grafikprogramm zusammengebastelt.

...

Ich denke da liegst du falsch... Meiner Meinung nach ist beides Blending und beides basiert auf dem Alphakanal, nur wird es in den von dir geposteten Bildern mit unterschiedlichen Faktoren gemischt (bei dem linken vom Grafikprogramm sogar noch verhellt)

Kannst mich natürlich vom Gegenteil überzeugen oO;

[MagicMaker]

Es ist kein Alphakanal vonnöten, weil die Mischsynthese so veranlagt ist, dass Schwarz
genau soviel Auswirkung hat, wie die RGB-Werte aussagen, nämlich Null.

[Kazesui]

Ich wär der erstbesten Person noch immer sehr verbunden, die mir das ermöglicht:

...

Sowas in der art?

[Rosa Canina]

@Kazesui:
Also ich kann da durchaus für MagicMaker sprechen, da ich ihn makertechnisch durch die lange Zeit doch sehr gut kenne, aber das werden ihm zu wenig Farben auf dem Screen sein XD
(Aka: Schreckliche Farbreduzierung :'D)
Er baut Bilder, wie sein obriges ja auch ohne ADD ein... er haut da einfach Bilder/Panoramas in das Spiel, bis die Makerszene vor der MB-Größe tot umfällt. ADD würde ihm theoretisch nur
ein wenig mehr Optik-Schönheit (keine Reduzierung) und vor allem... Erleichterung in der Erstellung geben.

Hab ich schon einmal erwähnt, dass ich endlich MMs Spiel spielen will. Seine Screens sind immer sehr, sehr schön und die Technik... von der spreche ich erst gar nicht, sonst werde ich noch
neidisch (muss halt nur jemand das Käferspray finden XD)

Noch eine Frage hinterher:
Wie hast du das hinbekommen? EInfach im Grafikprogramm oder ist das tatsächlich was maker-gebautes? Oo

[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.

[Davy Jones]

Durch einen Tippfehler wurde dafür jetzt IMMER der letzte Skill ausgeführt. Bäh.

Bitte nochmal patchen.

...

War das ein Patch für einen bestimmten Skript? Kann mit "Nachladen" grad nix anfangen.

Btw, wenn du schon am Patchen bist:

Was ich aus der Adresse rauslesen kann sagt mir, dass der Maker da versucht, auf ein nicht existierendes Partymitglied zuzugreifen. Die Entscheidung auf welches er zuzugreifen versucht kommt übrigens daher dass er meint, dieses (nicht existierende) Mitglied sei gerade ausgewählt. Das kann also passieren wenn der X-te Held der Party gerade am Zug ist oder als letzter Held am Zug war und nachher ein Remove Hero ausgeführt wird sodass die Party weniger als X Mitglieder hat.

Beispiel:

4 Helden in der Party
3. Held ist am Zug
Ein Event macht 2x Remove Hero
2 Helden in der Party
CRASH (Maker will auf 3. Held zugreifen)

Ich werde den Bug in meinem neuesten Projekt fixen.

...

Ein 2k3-Fehler aus einer alten PN. Könntest du den nochmal separat fixen? DynRPG scheint doch mehr was für Skripte zu sein als für das fixen von fiesen kleinen Bugs.