[RM2K3] Drückt dieser PP. die Performance des Makers ??

[TwoFace]

Uff, mir fällt grad ein: wenn ich nen Gegner abschieß... wird der Schaden, den der treffer verursacht via Picture für ne halbe Sekunde über seinem Kopf angezeigt und verschwindet dann wieder. Läuft halt über Koordinatenabfrage d.h. das Schadenspicture geht auch mit wenn sich der Zielevent in dieser zeit weiterbewegt. Also kurzum: in den Codes kommen auch Pictures zum Einsatz, klar. Die Anzahl an Events (aktive PP's) pro Map belaufen sich auf sagen wir mal noch knapp unter 20.

[Kelven]

Wie viele Gegner sind denn gleichzeitig aktiv? Die PPs alleine sollten kein Problem. Mein AKS vom Halloween-Contest lief auch mit ca. 20 auf einem 2,8 Ghz Pentium ohne Probleme.

[TwoFace]

7-10 Gegner. Also eig weniger als du hattest. Die PP's sind halt lang O.o Aber wenn du sagst, dass die im Normalfall kein Problem sind, glaub ich dir das. Hab auch nochmal kontrolliert, ob alles sauber gescriptet ist: überall 0er-Waits wo sie sein sollten... ruckelt trotzdem manchmal...

Hmm, vielleicht sollt ich das Spiel einfach von verschiedenen Leuten testen lassen, die mir dann am Ende sagen ob's bei ihnen lief oder nicht und mir anschließend die Daten ihres PC's durchgeben. Dann könnte ich zumindest einschränkend sagen was für 'nen PC und was für Hardware man braucht, damit das Spiel ruckelfrei läuft. Auch wenn sowas bei 'nem 2D-Spiel natürlich echt madig ist ...

[Kelven]

Die PPs aus meinem Spiel steuern die ganzen Gegner, also auch deren Bewegung, weshalb die Waits viel länger sind (bei Tempo Slow z. B. 16x0.0). Ich weiß jetzt nicht was bei dir in den PPs abläuft, aber wenn es innen keine Waits gibt, dann könnte ein 0.0 schon ein Problem sein.

[TwoFace]

Hmm, ich hab halt in PP's mit ends langen Scripten nur jeweils immer am Ende 'n 0.0er-Wait. Sollte ich mittendrin auch welche setzen, wenn sich's anbietet oder würde das nichts ändern? Ansonsten versuch ich mal die Waits auf 0.1 zu erhöhen. Hab Davy Jones gefragt ob das was bringt, er meinte ja.
'n Versuch wärs wert O.o

[Davy Jones]

Frage 1: Sind parallele Prozesse "performanceschonender", wenn sie nicht auf der Map als PP laufen, sondern über einen Common Event via Trigger Switch aktiviert oder auf der Map gecallt werden?

...

Parallele Prozesse sind die performancefressendste Event-Form die du dir aussuchen kannst. Nimm Call Event um die Sachen zu rufen, die nicht die ganze Zeit über in nem PP abgefragt werden müssen.

Frage 2: Drücken Parallele Prozesse, die genau für eine Sekunde lang aktiv sind, jedoch echt lang sind, die Performance überhaupt? Oder kann man das bei parallelen Prozessen generell ausschließen, wenn man mit 0er-Waits arbeitet?

...

PPs brauchen immer waits. Beim wait spielt folgendes eine Rolle:
- Ist dein PP gefüllt mit Koordinatenabfragen, die eine hohe Genauigkeit erfordern?
- Brauchst du den PP für schnelle Berechnungen von HP oder sonstwas? (beim Treffer des Gegners/Mainchars ließe sich das btw auch einfach callen).

Der beste wait für diese Sachen ist der 0.0 wait. Wenn das schon anfängt zu ruckeln, würde ichs mal mit 0.1 probieren und mal schauen ob da auch alles noch so schnell funktioniert wie du es dir vorstellst.

Nebenbei: Es gibt auch noch Erase Event, der einen PP dauerhaft "killt". Zumindest, solange du die Map nicht verlässt und wieder neu betrittst.

Noch ein Tipp: Wenn du PPs zusammenpacken kannst, würde ich das tun. Jeder PP weniger steigert die Performance, der Code der drinsteckt ist grad mal zweitranigig da er nacheinander abgespult wird (Ausnahme: Move Events ohne proceed with movement). Wenn du jetzt die gesamte HP-Abfrage aller Soldaten in einen einzigen PP mit 0.0 wait reinpackst, musst du nur gucken dass der Kram auch schnell genug reagiert, d. h. wenn du den finalen Treffer landest dass der Soldat auch gleich danach verschwindet und nicht erst 3 Sekunden auf der Map rumgurkt und erst dann vom PP ausgeschaltet wird. Wenn das nicht der Fall ist, würde ich den PP aufspalten und dann nochmal schauen, ob auch alles schnell genug vonstatten läuft. Dann haste halt 2 PPs mit HP-Abfragen, ist so ne Optimierungsgeschichte.