Programmwunsch und -erstellungsthread #2

[Cherry]

Ich glaube, sein Code hatte mit dir wenig zu tun, daher auch die Bezeichnung "KrimsKrams". bugmenot postet nur in diesen Thread auch alles was er so herumanalysiert. Dieses Kauderwelsch ist nicht dafür gedacht, vom Otto-Normal-User verstanden zu werden, keine Sorge.

[bugmenot]

[...]frage jetzt mit dem Plugin bei jedem Item ab, wie oft es ausgerüstet ist[...]

...

Über VariableOperation -> [Hero][Weapon Number] (und Shield usw.) erhält man doch die Item_ID des ausgerüsteten Items im EquipSlot, oder nicht? Dafür brauchst du niemanden aus der Party zu werfen.

[...]aber 90% davon ist für mich[...]

...

Cherry sagte schon alles Relevante. Liegt vielleicht nur daran, dass der KrimsKrams zu 90% aus Pseudo-Quellcode des RM2k(3) und zu 10% aus Fragezeichen besteht.


Über Variablen auf Item/Hero/Event_IDs und dazugehörige Parameter pointern zu können, sollte in Patch-Form möglich sein.
Ich schaue gerade, wie sich die Funktionen der Zuweisung von Str/Def/Int/Agi zusammenfassen lassen. Ein paar hundert Byte sollten da schon frei werden.



P.S.
Zugriffspunkte auf den Agi-Wert im Rm2k3-Code: 4ACEA2, 495911, 495B70, 495BB4, 495C5E, 49B0CD, 49B0F2, 49B106, 49B491, 49B49B, 49B4C0, 49B4D4, 49EB0A, 49EB22, 49EC1F, 49F469, 4A6928, 4AD25D, 4B7859, 4B8452, 4B8780, 4B8820, 4BEE16, 49C6E7, 49C6FB.

Da müssten irgendwo Funktionen des ATB-Systems mit bei sein.

[BDraw]

Über VariableOperation -> [Hero][Weapon Number] (und Shield usw.) erhält man doch die Item_ID des ausgerüsteten Items im EquipSlot, oder nicht? Dafür brauchst du niemanden aus der Party zu werfen.

...

... Du glaubst gar nicht, wie doof ich mir gerade vorkomme. Dankesehr. xD

[Rosa Canina]

Mal ne "dumme" Frage... gibt es eine Möglichkeit die LÄNGE einer Screen-Transition irgendwo festzulegen (über ResHack, whatever)?

Man muss sie nicht einstellen können, ein globaler Hack, der es z.B. doppelt so schnell macht, würde mir reichen ^^°

Edit: Geht um Rm2k3 V 1.08

[Cherry]

Redest du von Fade-In/Fade-Out (wie es der Maker für Systemmenüs und so verwendet) oder von den Effekt-Transitions (zoom, split, move, mosaic, etc.)? Sind nämlich intern zwei verschiedene Sachen.

[bugmenot]

Wenn es um Teleport/BattleStart/BattleEnd geht:

0x6BD7F set [90 90 90 90 90]
0x6BDEA set [90 90 90 90 90]

[QuickPatches]
InstaShowScreen=48E24B,9090909090
InstaHideScreen=48E2B6,9090909090

...

Show Screen darf hier nur nicht auf [Fade In] stehen. Man kann vor jedem Teleport oder ähnlichem per Tint Screen und dem wait darin die Länge der Transition selbst festlegen (oder Pictures für gemusterte Übergänge).

0x8D64B set [90 90 90 90 90]
0x8D6B6 set [90 90 90 90 90]

[Rosa Canina]

Ging um den regulären Show Screen... und dummerweise Fade-In. Also nix mit den Kampf-Übergängen ^^

Die Sache ist die... ich nutze es in einem kleinen Technikscript, dass vielleicht später mal was größeres werden könnte, um etwas einzublenden, dass ich
auf andere Art und Weise nur mit viel Aufwand einblenden könnte. Nur war das reguläre ShowScreen (quasi als Überblendung ohne Schwarz dazwischen)
einfach zu lang um auf Dauer nicht nervig zu werden.

Quasi so:
> Änderung
> Show Screen
= Sanfte Überblendung, die an der Stelle anders kaum möglich wäre (aber halt noch zu lang ist)

Dass ich das mit Screentones selbst machen kann, dass weiß ich. Hab immerschon eine ganze Latte fertige Spiele hier zum DL bereitgestellt XD

[bugmenot]

Hab immerschon eine ganze Latte fertige Spiele hier zum DL bereitgestellt XD

...

I know.

Es gibt keine Möglichkeit die Wartezeit auf etwas anderes als das oben benannte instant zu setzen.
(Ich sage das jetzt nur, weil ich zu faul bin mich durch hunderte an Befehlszeilen zu klicken. sub_48D200 ist ziemlich groß)


Der QuickPatch (oder HexHack wenn du kein DynRPG verwendest) schmeißt den ganzen Grafik-Effekt aller Übergänge außerhalb von Standart-Menüs raus.
Deswegen kann man die Wartezeit der Übergänge nur über Tint Screen + wait oder eigene Picture-Überblenden kontrollieren.

Oder meinst du mit Show Screen das Grafikupdate bei einer Veränderung auf der momentanen Map (wie zB. das Panorama ändern -> ShowScreen blocky = Panorama baut sich Block für Block neu auf)?

[Rosa Canina]

Oder meinst du mit Show Screen das Grafikupdate bei einer Veränderung auf der momentanen Map (wie zB. das Panorama ändern -> ShowScreen blocky = Panorama baut sich Block für Block neu auf)?

...

Dafür kann man es unter anderem nutzen, ja.

Aber wenn es nicht mit FadeIn geht, dann muss ich darauf verzichten oder das ganze eben auf die megaaufwendige Tour erledigen.

[bugmenot]

[...]auf die megaaufwendige Tour erledigen.

...

Es kann sein, dass wir aneinander vorbeireden. Vielleicht bin ich auch nur müde bzw. nicht müde genug.

Die Sequenz aller Ereignisse, die durch den InstaTransition-Patch abläuft:

Eventbefehl <Show Screen> (oder das Fade-In/Out bei Teleports und Battle)

[Bildschirm-Änderung instant anzeigen]

...deswegen muss man davor+danach eine Art Übergang einschieben:
[TintScreen black100% | wait x sec] -> [Bildschirm-Änderung instant anzeigen] -> [TintScreen normal | wait x sec]

Ähnliches beim <Hide Screen>. Du kannst auch gerne eine der Patchzeilen löschen und schauen, was passiert.


Edit:
Kann ich auch gerne parametrierbar machen. Also das instant per Switch/Variable an/ausschalten.

[Cherry]

@bugmenot: Man kann durchaus die Geschwindigkeit regeln. Wenn die Fade-In/Fade-Out Subs aufgerufen werden, bekommen die einen Parameter, das ist die Geschwindigkeit. Das ist ein Gleitkommawert vom Double-Typ, also 8 Bytes, deshalb ist der in 2 push-Befehle aufgeteilt.

Z.B. ist der Parameter anders beim Titlescreen, beim Game-Over und bei den Logos am Anfang. Weil da das Fade ja länger sein soll.

[bugmenot]

in 2 push-Befehle aufgeteilt.

...

Ah, mir geht ein Licht auf... glaube ich.
Sind das die [68]Push + [6A 00] vor jedem call ShowScreen oder call ClearScreen?

Edit:

[QuickPatches]
FastSystemTransition(Show)=48D295,08
FastSystemTransition(Hide)=48D2B4,08

...

[08] ist der Default-Wert. Höher setzen = schneller.
Bei [18] scheint es in etwa doppelt so schnell zu sein... oder eher dreifach.

Edit³:
Ist scheinbar nur der Teleport-Befehl.
Der InstaKram war irgendwie weniger "megaaufwendig". Ich schaue später mal in die anderen Eventbefehle hinein.

call Sleep

[Rosa Canina]

Ich dachte nicht, dass das so schwer verstehbar sei, anscheinend drücke ich mich nicht gut genug aus - oder wir waren alle wirklich zu müde.

Ich beschreibe es noch einmal gaaaaanz genau.
Es geht um den Event-Command SHOW SCREEN, welcher bei den Event-Commands auf Seite 2, linke Spalte, ganz unten steht.
Ich will den Spieler nicht teleportieren, keinen Kampf anfangen oder sonstige Dinge erledigen. Er bleibt einfach dort stehen, wo er eh schon
steht. Der Screen wird nicht gelöscht oder gefärbt und darf das auch nicht.
Der Show-Screen-Befehl wird daher ohne zuvorige Löschung des Bildschirms, ohne Ausblenden oder ähnliches benutzt. Dies hat den
Effekt, dass man den gesamten Screen fadet. So kann man z.B. sanfte Übergänge in ein Menü machen, ohne sämtliche variablen Werte
beim Einfaden schon berücksichtigen zu müssen.

Ich benutze es für eine riesige Grafikabfrage, welche mir bald 50 Bilder auf dem Screen verändert, die alle mit anderen Koordinaten laufen
und ich zu "faul" bin das alles über Move Pictures zu erledigen, da ich dann bald noch einmal so viele Bild IDs bräuchte, um wirklich jedes
auf dem Screen angezeigte Bild entsprechend gleichzeitig überblenden zu können.


Also wenn das irgendwie geht (soweit ich das jetzt richtig verstanden habe, wirkt der Code von bugmenot nur beim reinen Teleportbefehl, oder?),
dann wäre da sicherlich mehrere Stunden Arbeitserleichterung...

Und danke für die bisherige Hilfe ^^

[bugmenot]

(soweit ich das jetzt richtig verstanden habe, wirkt der Code nur beim reinen Teleportbefehl, oder?)

...

Sorry. Ich sehe gerade, dass sich die angegebenen Zeiten nur auf Überblenden von normal <--> Schwarz auswirken. Für's Fade-In gibt es eine gesonderte Funktion (sub_48CE7C).

Unter 48D017 werden die Frames angegeben, innerhalb denen der Überblendeffekt auftreten soll (nur kann man hier nicht die Hälfte angeben, da dann nur die Hälfte des Transparenzüberganges abläuft und dann sofort 100% zeigt), davor ist ein Aufruf einer Sleep-Funktion.
Ich schaue mal, wie man diese nur jeden zweiten Frame aufruft. Praktisch ein Frame Skip. Nur weiß ich jetzt noch nicht, ob das dann ruckelig aussehen wird... Sagt mir also gleich, ob die Idee für den Eimer ist.

Un attimo per favore... ...

[Rosa Canina]

Als leicht ruckelig würde mir nichts ausmachen. Der Standardübergang ist ja seeehr flüssig. Selbst die Hälfte der Frames wäre daher sicherlich kein optischer Bruch ^^

Und nochmal Danke, dass du da deine Zeit für opferst ^^

[bugmenot]

FastFadeIn x2

Das Ergebnis scheint recht flüssig zu sein.
Falls das immernoch zu langsam ist, ändern zu x3:
0xBD12C = [02] set [03]
0xBD134 = [01 74] set [00 75]

Danke für die Geduld.

[Rosa Canina]

Danke für DEINE Geduld ^^

Läuft wesentlich angenehmer und schöner jetzt, hab Dank für deine Mühen. Werde bei Gelegenheit auch das x3 noch probieren :3

[MagicMaker]

Könnte man vielleicht den Leistungsanspruch der RPG_RT aufpimpen, damit sie mehr pro Frame verarbeiten kann?
Mir geht es gewaltig auf den Keks, wenn bei mehr als 25 Loops mit etwas Zahlenschubsen und ein paar grafischen
Operationen ohne Framewaiter (die da einfach nicht hin DÜRFEN) schon ein obligatorisch blöder Halbsekunden-Lag
einsetzt, in dem die Anzeige erstmal schön stehen bleibt, nachdem es etwa genausolang halbwegs gut gegangen ist.

Die beiden Situationen wechseln sich ab. Bewegungen~>Stillstand~>Bewegungen~>Stillstand, relativ unspielbar.

[RPG2000 107+Des]

[Corti]

Ich halte es für realistischer und praktikabler deine Scripte anzupassen anstatt darauf zu hoffen, dass irgendwer auf wundersame Weise den Maker umzaubert.

Was ist das denn für ein komplexes System, dass 25 Loops benötigt? Ich würde empfehlen, verschiedene Dinge die in selben Zyklen passieren auch in einem parallelen Prozess aufzurufen.

[MagicMaker]

25 ist noch das, was geradeso fliessend ohne Halbsekundentakt-Stillstand funktioniert, sind aber noch
längst nicht die gewünschte Menge.

Bei dem Event handelt es sich um eine Verwaltung von bis zu 100 spawnenden durch den Bildschirm
fliegenden Objekten, die alle jeden Frame mit neuen Anweisungen gefüttert werden möchten und das
benötigt einiges an Codeinhalt, von dem noch nichtmal alles integriert ist, gerademal der DeSpawn bei
Kollision mit einem festen Hindernis auf der Map oder dem Bildschirmrand ist vorhanden, heisst auch
im Klartext, dass der Verarbeitungsumfang auf bedeutend weniger im Endprodukt herabsinken wird
und der ist jetzt schon im Schmerzgrenzenjenseits.