Programmwunsch und -erstellungsthread #2

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