Programmwunsch und -erstellungsthread #2

[IndependentArt]

"Anzeigeleisten"? ^^ Das kann natürlich auch sowas wie eine 4stellige Zahl sein, für die man dann bekanntlich 4x9 Forks braucht.

[Corti]

"Anzeigeleisten"? ^^ Das kann natürlich auch sowas wie eine 4stellige Zahl sein, für die man dann bekanntlich 4x9 Forks braucht.

...

Was du brauchst ist der Picture Pointer Patch. Damit brauchst du dann bekanntlich 0 Forks für eine Zahl.

[IndependentArt]

der hat nichts mit dyn zu tun oder? hab bei der liste der dyn sachen nix gefunden. hast du nen link zufällig?

(ich weiß natürlich nicht, wie das dann funktioniert. MarcL hat mir gestern versucht zu erklären, was ein pointer ist, so mit mäßigem erfolg. aber ich finde es bestimmt heraus ^^)

[Corti]

http://cherrytree.at/cms/lang/de/download/?did=19
Laut Readme findet sich in dem Demopropjekt ein Zahlenbeispiel. Viel Spass damit, wenns irgendwo klemmt, frag einfach.

[goldenroy]

MarcL hat mir gestern versucht zu erklären, was ein pointer ist, so mit mäßigem erfolg. aber ich finde es bestimmt heraus ^^)

...

Im dazugehörigen >>Thread<< gibt es einige weitere Erklärungen von Usern, die dir vielleicht weiterhelfen.

[bugmenot]

Gibt es eine Möglichkeit neue Checkmarks und Eingabefelder in die F8-Database einzubinden und mit entsprechenden Indeces (Ptr auf integer / booleans) zu verknüpfen?

Im 2k3 fehlt unter MonsterGroup bei dem Alignment/EnemyPlacement eine Checkbox für 'randomize group'.
Für alle Monster, abseits des ersten Monsters ohne hidden_flag, kann mit 50% Wahrscheinlichkeit die hidden_flag automatisch gesetzt werden.
Der dazugehörige Pointer wäre +1C auf MonsterGroupParam:
+04 = MonsterGroup_ID
+08 = MonsterGroup_Name
+0C = Ptr on MonsterList
+10 = TerrainAmount
+14 = Ptr on TerrainArray(?)
+18 = Ptr on BattleEvents
+1C = RandomizeHiding_flag (0|1 = false|true)
+20 = EnemyPlacement_flag (0|1 = manual|auto)




P.S.
random stuff:

Conditions, die HP abziehen, bleiben nicht bei 1 HP stehen:

[QuickPatches]
PoisonKills=4BF98E,89431485C0751089DA9242E87E06000089DAE8AFD5FDFF2B7B1431C0B07F89437833C989FA8BC3E82AFCFFFF90

...

CharSets im Shop bleiben farbig, selbst wenn entsprechende Items nicht genutzt werden können:

[QuickPatches]
NoGrayShopper=493EC0,00

...

RPG_RT2k v1.07:
0x70BDB: 01 set 00

Kein Aufleuchten bei EnemyBehavior: Transform.

[QuickPatches]
TransformFlash=4BDF08,5858589090

...

RPG_RT2k v1.07:
0x7EE92: E8 BD FD FF FF set 58 58 58 90 90

[QuickPatches]
RainColor_R=4C3416,B8,4C3417,#100
RainColor_G=4C340E,B8,4C340F,#100
RainColor_B=4C33E8,B8,4C33E9,#100
RainSaturation=4C33F0,B8,4C33F1,#100
RainSize=4C34A2,%24
RainOpacity=4C348B,%5

SnowColor_R=4C357E,B8,4C357F,#100
SnowColor_G=4C3576,B8,4C3577,#100
SnowColor_B=4C3550,B8,4C3551,#100
SnowSaturation=4C3558,B8,4C3559,#100
SnowOpacity=4C35F3,%5

FogColor_R=4C36E9,B8,4C36EA,#100
FogColor_G=4C36E1,B8,4C36E2,#100
FogColor_B=4C36BB,B8,4C36BC,#100
FogSaturation=4C36C3,B8,4C36C4,#100

SandColor_R=4C38AA,B8,4C38AB,#100
SandColor_G=4C38A2,B8,4C38A3,#100
SandColor_B=4C387C,B8,4C387D,#100
SandSaturation=4C3884,B8,4C3885,#100

...

RPG_RT2k v1.07:
0x91786: set B8 xx 00 00 00 RainColor_R
0x9177E: set B8 xx 00 00 00 RainColor_G
0x91757: set B8 xx 00 00 00 RainColor_B
0x91760: set B8 xx 00 00 00 RainSaturation
0x917F4: set xx RainOpacity
0x9180B: set xx RainSize

0x918E4 set B8 xx 00 00 00 Snow_R
0x918DC set B8 xx 00 00 00 Snow_G
0x918B6 set B8 xx 00 00 00 Snow_B
0x918BE: set B8 xx 00 00 00 SnowSaturation
0x91952: set xx SnowOpacity

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

[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)
?