Programmwunsch und -erstellungsthread #2

[bugmenot]

AntiLagSwitch 2k(3)
download AntiLagSwitch

Reduziert Ruckler bei exzessivem Gebrauch der Eventbefehle <Change Switch> und <Change Variable>.

(Der RPG-Maker ist nicht dafür ausgelegt viele Rechenoperationen in kurzer Zeit durchzuführen. Da bei jedem <Change Switch> oder <Change Variable> alle Events auf der Map einmal geupdatet werden, kommt es vorallem auf großen Maps mit vielen Events gerne mal zu Frameeinbrüchen.)

Dieser Patch umgeht bei jedem <Change Switch> oder <Change Variable> das Updaten der Events, solange Switch[1000] = ON. Ein Change Switch[1000] = OFF kann dann selber ein Event-Update auslösen. (Dann werden die Conditions auf der ersten Eventseite wieder abgeprüft und das Starten neuer ParallelProcesses oder Eventgrafik-Updates ermöglicht. Kein Starten neuer Events und keine Änderung der Eventgrafiken, solange Switch[1000] = ON)

download LunarIPS
Erster Schritt: legt euch eine Sicherungskopie eurer RPG_RT.exe an (für den Fall der Fälle)
Lunar IPS öffnen -> apply IPS patch -> .ips-Datei (den Patch) wählen > Dateityp: all types -> RPG_RT.exe auswählen

Nach dem Patchen lässt sich die Switch_ID in der RPG_RT.exe unter 0x85DDC + 0x8550E (2k) und 0xAC7CF + 0xABEEE (2k3) per HexEditor umstellen. Oder packt den Patch in den Ordner DynPatches und:

[QuickPatches]
AntiLagSwitch=4AD3CF,#1000,4ACAEE,#1000

...

Reduces lag spikes when excessively using the event commands <Change Switch> and <Change Variable>.

(The RPG-Maker isn't designed to handle many calculations within a short amount of time. Given that each <Change Switch> or <Change Variable> updates each and every event on the entire map, there is a tendency for it to cause dropping frame rates on large maps with lots of events.)

This patch bypasses the updating of events when using <Change Switch> or <Change Variable>, as long as Switch[1000] = ON. Using Change Switch[1000] = OFF can cause an event update by itself. (Conditions on the first event page will be tested afterwards and allow new ParallelProcesses to start or event graphics to update. New events won't start and no event graphics will change as long as Switch[1000] = ON)

download LunarIPS
First step: make a backup of your RPG_RT.exe (just in case)
open Lunar IPS -> apply IPS patch -> select the .ips file (this patch) -> file type: all types -> select the RPG_RT.exe

Upon patching you can change the Switch_ID in the RPG_RT.exe at 0x85DDC + 0x8550E (2k) and 0xAC7CF + 0xABEEE (2k3) by using a HexEditor. Or put this patch into your DynPatches folder and:

[QuickPatches]
AntiLagSwitch=4AD3CF,#1000,4ACAEE,#1000

...

[Davy Jones]

Also werden nur die Events geupdated, die von einem Change Switch bzw. Change Variable direkt betroffen sind?

[bugmenot]

Erm... immer wenn irgendetwas passiert (oder der entsprechende Eventbefehl erfolgt), das die PreConditions auf der linken Seite von Events erfüllen könnte (ChangeSwitch, ChangeVariable, AddItem, ChangeParty, ChangeTimer) ... erfolgt nach jedem solchen Eventbefehl ein EventUpdate, das ALLE Events auf der momentanen Map und ALLE CommonEvents anvisiert.

Wenn man im Hintergrund irgendwelche Logik- oder Arithmetik-Prozesse laufen hat, die aus zig Zeilen bestehen, die in jedem Frame wiederholt werden... kann man entweder einen 0.0 wait setzen (damit das Spiel Zeit hat, sich wieder zu beruhigen... dann muss man aber auch mittendrin waits setzen, weil 2 Frames warten statt vorher 1 ohne wait auch nicht viel bringen könnte...) ...oder halt das Auslagern von Rechenarbeit auf das Durchchecken von mehreren hundert Events unterbinden.

Diese Maker waren nie darauf ausgelegt, mit vorgegebenen Mitteln, irgendetwas großes durch den Nutzer ausrechnen zu lassen.

Der Patch wird leider kein generelles Laggen durch riesige Maps mit hunderten sich bewegenden Events oder durch ständige Festplattenzugriffe durch unnöttiges <ShowPicture> beheben.


Edit:

Parallele Events laufen nicht komplett durcheinander. Ein Event läuft solange ungestört, bis es entweder einige Tausend Befehle ausgeführt hat (weiß gerade die Zahl nicht) oder an einen Befehl kommt, der bis zum nächsten Frame wartet (dazu gehört Wait, aber auch das Ende eines PPs oder Befehle wie Open Save Menu, etc.). Daher, wenn man nicht eine Schleife ohne Wait baut (was man eh nicht sollte), sodass man an das Befehlslimit kommt, kann man davon ausgehen, dass zwischen zwei Befehlen die nicht auf das nächste Frame warten (und dazu gehören ja Variablen-/Switch-Operationen und Bedingungen) nichts anderes dazwischenfunkt.

...

Solange man einen Block an ForkConditions + Switches + Variables hintereinanderreiht und vor und nach dem Block Switch[1000] an/ausschaltet, sollte es selbst bei parallel laufenden Events keine Probleme geben.

[MagicMaker]

Die Checkerei wird also bei jeder Aktion durchgeführt, die die Seitenbedingungen betreffen könnte?

Es erschliesst sich mir halbwegs, warum das bei dem Event durchgeführt wird, aus dem der Befehl stammt,
da sich mitten im Frame etwas Wichtiges ändern kann, aber alle überprüfen? Es hätte ja eigentlich gereicht,
wenn diese durchgecheckt werden, sobald sie in der Ausführung im derzeitigen Frame dran sind. òo

[bugmenot]

Die Checkerei wird also bei jeder Aktion durchgeführt, die die Seitenbedingungen betreffen könnte?

...

Was mit den CommonEvents ist, kann ich nicht genau sagen. Aber bezüglich von MapEvents werden in einer 'for i = 1 to EventAmount'-Schleife die Parameter des jeweiligen Events abgerufen und gleich hinterher die Seitenbedingungen durchgecheckt. Bei jeder solchen Aktion, die ein EventUpdate ausführt. Ohne irgendwo mittendrin zu warten.

[Raildex]

Sagt mal Leute, wäre es möglich eine Art eigene Scene zusammenzubauen?
Also ich meine ein komplett eigenes Menü, aber im Standardstil, ohne Pictures etc. zu verwenden. Dass man das ganze praktisch hardcoded?

[Cherry]

AntiLagSwitch 2k(3)
download AntiLagSwitch

Reduziert Ruckler bei exzessivem Gebrauch der Eventbefehle <Change Switch> und <Change Variable>.

(Der RPG-Maker ist nicht dafür ausgelegt viele Rechenoperationen in kurzer Zeit durchzuführen. Da bei jedem <Change Switch> oder <Change Variable> alle Events auf der Map einmal geupdatet werden, kommt es vorallem auf großen Maps mit vielen Events gerne mal zu Frameeinbrüchen.)

Dieser Patch umgeht bei jedem <Change Switch> oder <Change Variable> das Updaten der Events, solange Switch[1000] = ON. Ein Change Switch[1000] = OFF kann dann selber ein Event-Update auslösen. (Dann werden die Conditions auf der ersten Eventseite wieder abgeprüft und das Starten neuer ParallelProcesses oder Eventgrafik-Updates ermöglicht. Kein Starten neuer Events und keine Änderung der Eventgrafiken, solange Switch[1000] = ON)

download LunarIPS
Erster Schritt: legt euch eine Sicherungskopie eurer RPG_RT.exe an (für den Fall der Fälle)
Lunar IPS öffnen -> apply IPS patch -> .ips-Datei (den Patch) wählen > Dateityp: all types -> RPG_RT.exe auswählen

Nach dem Patchen lässt sich die Switch_ID in der RPG_RT.exe unter 0x85DDC + 0x8550E (2k) und 0xAC7CF + 0xABEEE (2k3) per HexEditor umstellen. Oder packt den Patch in den Ordner DynPatches und:

Reduces lag spikes when excessively using the event commands <Change Switch> and <Change Variable>.

(The RPG-Maker isn't designed to handle many calculations within a short amount of time. Given that each <Change Switch> or <Change Variable> updates each and every event on the entire map, there is a tendency for it to cause dropping frame rates on large maps with lots of events.)

This patch bypasses the updating of events when using <Change Switch> or <Change Variable>, as long as Switch[1000] = ON. Using Change Switch[1000] = OFF can cause an event update by itself. (Conditions on the first event page will be tested afterwards and allow new ParallelProcesses to start or event graphics to update. New events won't start and no event graphics will change as long as Switch[1000] = ON)

download LunarIPS
First step: make a backup of your RPG_RT.exe (just in case)
open Lunar IPS -> apply IPS patch -> select the .ips file (this patch) -> file type: all types -> select the RPG_RT.exe

Upon patching you can change the Switch_ID in the RPG_RT.exe at 0x85DDC + 0x8550E (2k) and 0xAC7CF + 0xABEEE (2k3) by using a HexEditor. Or put this patch into your DynPatches folder and:

...

Könnten wir nicht die UpdateEvents-Funktion so umbauen, dass sie nur ein Flag setzt, und am Ende der Eventverarbeitung in einem Frame das eigentliche UpdateEvents ausführen, wenn das Flag gesetzt ist? Ich seh momentan keinen Grund warum man mehr als 1x pro Frame die Events aktualisieren sollte, was meinst du?

[bugmenot]

[...]was meinst du?

...

Der Einfall ist mir vor vier Monaten auch in den Sinn gekommen. Mir war aber kein freier Platz in den Pointern bekannt (ohne groß zusammenfassen + anpassen zu müssen) um die Flag unterzubringen, und keine Funktion bekannt, welche jeden Frame nur 1 mal abgerufen wird.

Das lässt sich beides doch extern in einer DynRPG-Routine unterbringen?
...und die loop in loc_4AB8C5 verlassen, solange Flag = true (nach Durchlauf der Schleife setzen) und das ding/flag halt nach jedem Frame per externe Funktion auf false (= do not block EvUpdate) flippen. Warum brauchst du dafür meinen Konsens?



P.S.

[...]bis irgendjemandem einfällt, wie die Kämpfe nicht mehr crashen.

...

Mir ist etwas eingefallen:

download MapInMenu

Keine Ahnung, was ein transparentes F9-Menü bringen soll. Credits an Cherry's erste 2k3 Version.

[Cherry]

Ich würd mir meinen eigenen Platz für das Flag suchen, z.B. 4CE100, oder irgendwo ein unbenutztes Byte klauen, wie z.B. Offset 5 (nach der Scene, die nur als Byte und nicht als DWord verwendet wird) in TLcfgSystem, also [[4CDC7C]]+5.
Dann würde ich das richtige UpdateEvents (wenn nötig) einfach bei 4903AB machen, also nachdem die Scene geupdated, aber noch nicht gedrawt wurde (weil letzteres vom Maker ja auch geskipt werden kann wenn ersteres zu lange gedauert hat).

Ich werd das bei Gelegenheit mal einbauen, wenn du es noch nicht gemacht hast bis dahin.

Deinen Konsens: Naja, weil du den AntiLagSwitch gemacht hast, dich also schon mit den Auswirkungen auseinandergesetzt hast, wenn man UpdateEvents nicht aufruft, und daher, sollte meine Idee fehlerhaft sein, was gesagt hättest

@all: Kann mir mal wer ein Spiel verlinken was derbe laggt (und zwar nicht wegen Show Picture)? Ein Real Life Example wär praktisch.

Btw, ich frag mich ja auch woran es liegt, dass das Rotieren von größeren Pictures so extrem laggt. Ich vermute ja, dass sich der Frameskip-Mechanismus da selber ein Ei legt, sobald das Updaten länger dauert als 1/60 Sekunde (weil es das ja jedes Frame braucht).

[bugmenot]

[[4CDC7C]]+5

...

... du meinst sicher das Byte neben der GameScene, welche durch den [MainPtr]+4 dargestellt wird?
Wenn nicht, dafür sind die 90 90 da. GameScene auf [+4] wird sowieso überall als BytePtr gesetzt/abgefragt bzw. mit zero extend für jmp off_4...[eax*4] ausgelesen.

Eine nicht so schwachsinnige Version.
UpdateEvents setzt eine Byte_flag und in sub_4A35D0 wird dann die flag wieder = false gesetzt und das eigentliche UpdateEvents durchgeführt (ohne nach dem ersten EventBefehl zu blockieren).

@all: Kann mir mal wer ein Spiel verlinken was derbe laggt

...

Frag mal Itaju, ob er noch den Downloadlink der semi-aktuellen Version von AtV hat.
Oder copy&paste dir ein paar dutzend Events mit 100 EventPages (zählt dann als ca. 50 Events) zusammen und einige hundert mal inc(Var1) in einem parallel process.

[Cherry]

Ja, sollte alles beschreibbar sein... was crasht da bei dir?

[Davy Jones]

@all: Kann mir mal wer ein Spiel verlinken was derbe laggt (und zwar nicht wegen Show Picture)? Ein Real Life Example wär praktisch.

...

Alone - Cold Winter und Eternal Legends 2. Allerdings ist ersteres mit Molebox verschlüsselt (deswegen auch die Ruckler) und bei letzterem kommt es auf den PC an, von welchem es gestartet wird. Bei einigen laggt es sich langsam bis zur Unspielbarkeit, bei anderen passiert garnix.

Ansonsten fallen mir keine Spiele ein, die stark ruckeln.

[MarcL]

Alone - Cold Winter und Eternal Legends 2. Allerdings ist ersteres mit Molebox verschlüsselt (deswegen auch die Ruckler) und bei letzterem kommt es auf den PC an, von welchem es gestartet wird. Bei einigen laggt es sich langsam bis zur Unspielbarkeit, bei anderen passiert garnix.
Ansonsten fallen mir keine Spiele ein, die stark ruckeln.

...

Weiß zwar nicht genau worums geht, aber mein Spiel (Legend of the Silverstone) ruckelt im Gebirge (MarcLMaps-->GebirgeTeilLinks/GebirgeRECHTSunten) ziemlich stark, da sind auf den Maps ~1000-2000 Events? und dann noch PPs... Wenn man den alten AntiLag einschaltet, geht es merklich schneller, aber ich müsste erstmal kucken, worauf ich dann noch achten müsste, damit sonst von der Technik alles hinaut (man muss das Teil ja zu bestimmten Zeiten wieder ausschalten bzw. resetten oder so....)

[bugmenot]

Ja, sollte alles beschreibbar sein... was crasht da bei dir?

...

Das.

Edit:
...
Die Festlegung des Datenbereiches mit einem FF FF FF FF 01 00 00 00 fehlt?

[Cherry]

4ACB17 ist ja mitten im Code-Segment, das ist natürlich nicht beschreibbar... drum hatte ich ja zwei Vorschläge im Datensegment respektive in einem zur Laufzeit allozierten beschreibbaren Speicherbereich gebracht.
See also: http://msdn.microsoft.com/en-us/library/ms809762.aspx

Und FF FF FF FF 01 00 00 00 hat damit nix zu tun, das ist nämlich keine "Festlegung eines Datenbereiches" sondern gibt die Stringlänge (und das ist kein String) an.

Kleiner Exkurs zu Delphi-Strings, falls es dich interessiert: Delphi-Strings sind nämlich ein relativ geniales Konzept: Sie sind quasi erweiterte C-Strings. C-Strings sind ja einfach nullterminierte Strings ohne Längenangabe, d.h. da steht dann z.B. "Hello World" + ein 00-Byte im Speicher, letzteres gibt das Ende des Strings an. Das heißt natürlich im Umkehrschluss, dass ein String selber kein 00-Byte enthalten kann, und dass jedes mal die Bytes im String durchgezählt werden müssen wenn man dessen Länge rausfinden will. Delphi hängt davor noch zwei DWords an (davor, weil man dann den eigentlichen Stringpointer genauso Delphi- und C-/WinAPI-Funktionen geben kann und es funktioniert). Und zwar Reference Counter und Länge. Angenommen, eax ist gerade ein Pointer auf den eigentlichen String (also quasi auf das "H"-Byte in "Hello World"), dann kann man mit [eax-4] die Länge des Strings und mit [eax-8] den Reference Counter auswählen. Der Reference Counter wird für zur Laufzeit erstellte Strings verwendet - dadurch kann derselbe String mehrfach verwendet werden, ohne jedes mal neu erzeugt zu werden, solange bis ihn keiner mehr verwendet, dann wird der Speicher freigegeben. Nun sind aber hardgecodete Strings im Code-Segment anders, weil sie eben nicht zur Laufzeit erstellt worden sind, können sie auch keinen Reference Counter haben (er wäre ohnehin nicht beschreibbar weil Code-Segment). Deshalb ist der Wert des Reference Counters bei Stringkonstanten -1 (FF FF FF FF), als "Special Value" quasi. Leere Strings werden übrigens gar nicht gespeichert, sondern durch einen Nullpointer repräsentiert.
See also: http://www.codexterity.com/delphistrings.htm (runterscrollen zu AnsiString)

EDIT:
Sag mal, was machst du denn da eigentlich? Wieso baust du so viel Code um, an nichts damit zu tun habenden Stellen, sodass andere Patches oder Offsetsuchprogramme daran verzweifeln, anstatt eine vernünftige Codecave an einer unbenutzen Stelle zu verwenden? Da ist so viel nicht verwendet...

Um nicht alles unnötig zu verkomplizieren, würde ich dich dringend bitten, nur mehr minimale Änderungen am Code vorzunehmen, und zwar da, wo es auch logisch hingehört. Wir müssen unsere Codecaves natürlich koordinieren, deshalb wird ich sagen, du kannst im 2k3 446D30-449DD3 haben. (Da sind Funktionen für Kontextmenüs, aber es gibt ja keine im Spiel, kann man also überschreiben). 442600-443A6F und 45CDF4-45D84B bitte nicht anrühren, das ist für DynRPG, und irgendwo in der Nähe von 433XXX hab ich noch Zeugs für PicPointerPatch, wenn ich mich Recht erinnere. Die Zone nach dem Ende des Codes ab 4C9D10 ist auch schon belegt, BetterAEP z.B.

Beim 2k kannst du 432CAC-436FE3 haben.
Ist das OK für dich?

Ich hätte noch eine große Bitte an dich... ich hab mir nämlich mit meinem Vorschlag, wo du den Code der 1x pro Frame ausgeführt wird, hintun sollst, selber ein Ei gelegt. Genau die Stelle brauche ich nämlich in meinem neuen Projekt, einem Debugger, und ich habe eh überlegt ob ich eine andere Lösung finde, aber es ist mir fast unmöglich, mit deiner Änderung da noch vernünftig zu arbeiten. Also bitte sei so nett und lege den Code stattdessen auf 4A35D0, das ist der Anfang der Routine die 1x pro Frame die Map updated. Sollte für dich denselben Effekt haben, ohne dass dann mein Debugger bei keinen Projekten mit AntiLagSwitch+ funktioniert! Vielen lieben Dank!

[bugmenot]

download AntiLag(Fast)

Jetzt sollten eigentlich alle Fehler raus sein.


download ALS DePatch
(entfernt den AntiLagSwitch Patch restlos, wenn man ihn nicht im Ordner DynPatches hatte, sondern direkt auf die RT gepatcht hat).


CodeCaves:
432CAC..432D02 (2k v1.07 )
446D30..446D85 (2k3 v1.08 )

Ich stell heute noch welche für 2k v1.51 Value! und 2k3 v1.09 raus. Wer was anderes benutzt bitte laut rufen.

Da ist so viel nicht verwendet...

...

Da hat eine gewisse Person vor knapp 17 Monaten etwas anderes behauptet.

Wieso baust du so viel Code um, an nichts damit zu tun habenden Stellen

...

1. ...hat sich erledigt... (DePatch)
2. Generell: wenn einem gesagt wird, dass in der RPG_RT kein Platz mehr ist, dann macht man sich Platz. Ohne vorher raten zu müssen, welche Funktionen im Programm nie ausgeführt werden.

[Cherry]

Ja, du hast Recht, ich hab vor 17 Monaten echt was anderes geschrieben (da kannte ich diese Stelle auch noch nicht, aber das ist jetzt egal). Und wenn ich jetzt meinen Satz von vorher lese, nämlich den da: "Sag mal, was machst du denn da eigentlich? Wieso baust du so viel Code um, an nichts damit zu tun habenden Stellen, sodass andere Patches oder Offsetsuchprogramme daran verzweifeln, anstatt eine vernünftige Codecave an einer unbenutzen Stelle zu verwenden?", dann denke ich mir "WTF, klingt das unfreundlich". Dafür möchte ich mich wirklich entschuldigen, weil es nicht deine Schuld war, ich glaube ich war gestern gerade prinzipiell weniger guter Laune, was nicht an dir lag, und hab mich dann darüber geärgert dass plötzlich mein Zeugs mit deinem Patch nicht mehr ging und ich dann auch noch selber dir die Adresse gesagt habe. Ich hätte auf mich selber sauer sein sollen, also vergiss es bitte einfach, es tut mir Leid. Danke, dass du dir überhaupt die Arbeit machst a) diese Patches zu machen und b) noch meinen Bitten nachzukommen.

[Ghabry]

Könnten wir nicht die UpdateEvents-Funktion so umbauen, dass sie nur ein Flag setzt, und am Ende der Eventverarbeitung in einem Frame das eigentliche UpdateEvents ausführen, wenn das Flag gesetzt ist? Ich seh momentan keinen Grund warum man mehr als 1x pro Frame die Events aktualisieren sollte, was meinst du?

...

Also ich hab nicht probiert, ob das mit diesem neuen Antilag-Patch Probleme verursacht, aber eine Situation würde mir einfallen, wo man zwischendurch neu evaluieren muss:

Code:

Event:

Seite 1 (Paralleler Prozess, ohne Startbedingung):

Message "A"
Schalter 1 an
Message "B"

Seite 2 (Autostart, Bedingung Schalter 1 an):

Message "C"

Ausgabe muss sein: AC, das parallele Event bricht sofort ab, sobald eine andere Bedingung erfüllt ist.
Wenn Seite 1 nen anderer Typ ist, ist die Ausgabe immer "ABC".

Das Verhalten weicht übrigens beim XP und neuer ab, da ist die Ausgabe auch bei parallelen Events "ABC", ist also ne 2k/3-Besonderheit.

[bugmenot]

Also ich hab nicht probiert, ob das mit diesem neuen Antilag-Patch Probleme verursacht

...

Ohne Patch: AC
Mit Patch: ABC
Mit Patch mit [0.0 Wait] vor B: AC

zwischendurch neu evaluieren

...

Inwiefern?
Wieder zum Ausgangszustand des "alle Events abklappern, wo Eventbedingungen erfüllt sein könnten und viele Frameeinbrüche verursachen" zurück?
Einen CommentCommand @Update für einen erzwungenen Eventupdate einführen? (wovon ältere Spiele dann nichts haben)
Sich darüber aufregen wie dämlich es sich anhört, den Code für irgendeine Funktion auf mehrere EventPages zu verteilen statt irgendwo intern zu verschachteln oder <CallEvent> richtig zu nutzen?
Edit:
"EventUpdate(Global)" = 1x je Frame, updatet jedes Event auf der Map nach einem Eventbefehl
und
"EventUpdate(Local)" = nach jedem einzelnen Eventbefehl, updatet nur das Event, aus dem der Befehl hervorgeht (+eigene EventPages)
?

[Ghabry]

Also eigentlich wollte ich mich nicht in die Diskussion einmischen, sondern Cherry ein Beispiel bringen, wo die Annahme nicht funktioniert, weil ihm spontan keins einfiel.

Die einfachste Lösung wäre natürlich nur 1x neu zu evaluieren. Würde ich auch persönlich für die sauberste halten, als so ein rumgefrickel wie @Update oben hinzuschreiben. Vorm patchen sollte sich nur der Entwickler bewusst sein, dass seine parallelen Events im Spiel sich anders Verhalten, wenn der von mir genannte Fall eintritt.