Langer CC...

[lokipoki]

Hey.

Habs selber noch nicht ausprobiert. Wenn ich einen ganz, ganz langen CC mache, wird dann mein Spiel ruckeln? Ich habe den CC zur Abfrage meiner Teleporter...

[makenshi]

Das kann man so pauschal nicht sagen.
Es kommt darauf an wie das CE aufgebaut ist.
Wenn viele ressourcenfressende Befehle drin sind, dann wird es
natürlich mehr Leistung benötigen.
Bei vielen Forks ist es nicht die soo schlimm, wenn du dich an
einen richtigen Aufbau gehalten hast.

Code:

IF(variable==1){
  //effekt
  }else IF(variable==2){
usw.

Bau das ganze also so, das nicht benötigte Codeteile übersprungen
werden. Für weitere Tipps oder ähnliches müsste man das Event mal sehen.

[Nemica]

Ein CC? Du meinst wohl nen CE, was? Na egal, die Länge dürfte net
stören, aber irgendwann wirds wohl geringfügigere Verzögerungen geben,
sodass die späteren Kommandos länger brauchen, weil sich der Maker ja durch
den ganzen Code durcharbeiten muss.

Ruckeln tut das Spiel afaik nur, wenn viele Events gleichzeitig laufen.

edit: Hör auf vor mir zu posten, Maki ^^

[lokipoki]

Das kann man so pauschal nicht sagen.
Es kommt darauf an wie das CE aufgebaut ist.
Wenn viele ressourcenfressende Befehle drin sind, dann wird es
natürlich mehr Leistung benötigen.
Bei vielen Forks ist es nicht die soo schlimm, wenn du dich an
einen richtigen Aufbau gehalten hast.

Code:

IF(variable==1){
  //effekt
  }else IF(variable==2){
usw.

Bau das ganze also so, das nicht benötigte Codeteile übersprungen
werden. Für weitere Tipps oder ähnliches müsste man das Event mal sehen.

...

Ich habe zb viele Comments drin. Sollten die stören?

PSE muss natürlich heissen...

[makenshi]

Nein, das ist schon ok so.
Ich kommentiere auch recht ausführlich. So bleibt das ganze
wenigstens lesbar.

[CapSeb]

Da fällt mir wieder die Frage ein, die mich dauernd verfolgt:
Wie verarbeitet der Maker ein Event?

Wenn es zwei Events gibt, gibt der Maker dann das neue Ergebnis einer Variable nach jeder Zeile aus oder arbeitet der mit Kopien der Variablen bis zum Ende des Events? Schreibt er das Ergebnis der Variablenkopien erst danach auf die Originalvariablen? Und wie sieht das bei CEs aus? Genau das gleiche Schema? Und Waits - zählen die als Ausgabepause, das heißt wird zum Zeitpunkte eines Waits die veränderte Variable für andere Events "freigegeben"?
(Und sind CE-Calls fertig bevor die nächste Zeile des Aufruf-Events bearbeitet wird? o_O)

--> Ruckelt ein Spiel wenn ein Event andauernd Variablen hin und her rechnet, die für den eigentlichen Spielablauf nicht direkt relevant sind?

Vielleicht weiß ja einer die Antworten auf all die Fragen... Bis her hab ich zumindest noch nichts zu diesem Thema im Forum gelesen.


CapSeb

[Stoep]

Der RPG-Maker arbeitet die Events von oben nach unten durch. Dabei
wird nichts zwischengespeichert oder so. Wenn du ein Event machst das
bspw. die Variable 1 auf den Wert 100 setzt dann macht der Maker das auch
sofort auch wenn danach eine Wait von bspw. 10.0 sec kommt.

Bei Common Events ist das genau dasselbe außer du rufst das CE über den
Call-Befehl auf. Dann unterbricht der Maker das Event in dem das CE gecalled
wird und bearbeit es erst wieder wenn er das CE abgearbeitet hat (das gilt
wiederum auch für normlae Events die "gecalled" werden)

Sowas kann man aber auch sehr einfach testen indem man ein Projekt im
Testplay startet und sich dann die Variablen und Switches mit "F9" anschaut.

--> Ruckelt ein Spiel wenn ein Event andauernd Variablen hin und her rechnet, die für den eigentlichen Spielablauf nicht direkt relevant sind

...

Das kannst du doch auch ganz leicht testen indem du es halt ausprobiert O_o
Wenn denn etwas ruckelt dann empfiehlt es sich immer eine wait von min.
0.0 sec am Ende eines jeden Codes der auf PP läuft zu setzen (mach ich
übrigens auch dann wenn's nicht ruckelt^_-)
Und wenn du die Codes so aufbaust wie es makenshi gepostet hat dann
ist das sicherlich auch sehr gut für die Performance.

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt^__^

Gruß
Stoep

[CapSeb]

Wenn du ein Event machst das bspw. die Variable 1 auf den Wert 100 setzt, dann macht der Maker das auch sofort, auch wenn danach eine Wait von bspw. 10.0 sec kommt.

...

Ok, ist klar. Aber wie ist das mit zwei Events die "parallel", also per PP, arbeiten. Der Maker bzw. PC verarbeitet ja immer nur eine Operationen auf einmal. Ein wirkliches paralleles Arbeiten wird also nur vorgegaukelt, weil er so schnell arbeitet - Stichpunkt ruckeln.

Wie macht er aber dieses Vortäuschen der Gleichzeitigkeit? Geht er erst komplett Event 1 durch (von oben nach unten ) und dann Nr. 2 usw. bis schließlich wieder Event Nr. 1 dran ist? Kann man mit _zwischenzeitlichen_ Veränderungen in Event Nr. 1 (X+100; wait; X-100) also keine Rechnung in Event Nr. 2 verändern?

Wie gesagt hab ich mich das schon mal gefragt. Und es ging dabei auch um das Problem der Waits. Wird während eines Waits alles eingefroren? Sehr unwahrscheinlich. Ein Event Nr.1, das nur ein Wait von 10 Sekunden beinhalten, verhindert nicht das "parallele" Ausführen von Event 2. Das aber wiederrum bedeutet, dass er springt! Event Nr. 1 wird bis zum Wait ausgeführt, dann kommt Event Nr.2 und wenn das Wait aus Nr. 1 fertig ist gehts mit Event 1 weiter. Und Waits gibts in vielerlei Ausführung, zB. Move Picutre mit "Wait until done". Das ganze würde zu einem ewigen Hin- und Hergespringe führen.

Und was ist nun mit dem besagten _zwischenzeitlichen_ Verändern von Variablen?
In Event 1 wird jetzt vom Anwender noch ein Change Variable [x+100] vor dem Wait eingefügt und dahinter ein Change Variable [x-100], sodass das Event aus 3 Zeilen besteht. In Event Nr. 2 wird genau diese Variable verwendet. Welches X nimmt er? Vielleicht doch die Kopie des Original-X vom Beginn des Events, damit nichts zerstört wird?

Ich glaub so einfach, "oben nach unten" ist da nicht. Fragt sich nur, wann er Variablen nach außen frei gibt und wann nicht.

Das kannst du doch auch ganz leicht testen indem du es halt ausprobiert O_o

...

Wär doch langweilig, so ganz allein. Ich rede lieber erstmal vorher drüber.


CapSeb

[CapSeb]

*push*

Weiß keiner wie der Maker arbeitet? Hat niemand Lust zu schreiben? Oder sind in diesem Unterforum nur Techniknoobs unterwegs und alle anderen haben den Thread nicht gelesen?

...ich werde es nie erfahren.
Falls jetzt wieder keiner antwortet, mache ich nächstes Weihnachten noch einen Push, vielleicht hat sich bis dahin ja die Com soweit verändert, dass die Frage beantwortet werden kann.
nton:

[Nemica]

Wieso sollte der PC/Maker nur einen Befehl auf einmal verarbeiten können?

Was die Zeit angeht, stand die Dauer verschiedener Befehle net mal in dem
Technikwissen-Thread? Somit kannste dir locker ausrechenen, was zuerst
ausgeführt wird.

Ja ja, Echtzeitverarbeitung ist nicht nur beim Makern ein Problem~

Ich glaube, ein PP ist wirklich "P", das heißt, er wird wirklich parallel ausgeführt.

Und wieso sollte der Maker mit Variablenkopien arbeiten? Diese Variablen sind
keine echten Parameter/Argumente, wie wir sie vom Programmieren kennen.
Sie sind sozusagen global.

[CapSeb]

Also ich habs mal getestet ^^

Der Maker arbeitet anscheinend in einem Rechentakt immer einen Befehl pro parallel Event (wartet also wahrscheinlich diesen Takt lang bis alle Events einen Schritt weiter sind). Switch umschalten, Variablen einstellen uÄ. scheint die gleiche Zeit, also einen Rechentakt, zu benötigen.

Ich habe folgenden Test versucht:

1. erstellt ein neues Projekt
2. Map verkleinern (20x15) und mit Gras-Chips füllen
3. zwei Events erstellen mir der Start Condition "Parallel Process"
4. die drei ersten Variablen benennen: "test", "zähler1" und "zähler2"
5. das erste Event mit diesem Code füllen:

Code:

< > Label 1#
< > Change Variable: Var[0001:test] + 1
< > Change Switch: Var[0001] Switch ON
< > Change Switch: Var[0001] Switch ON
< > Change Switch: Var[0001] Switch ON
< > Change Switch: Var[0001] Switch ON
< > Change Switch: Var[0001] Switch ON
< > Change Variable: Var[0001:test] - 1
< > Change Variable: Var[0001:zähler1] + 1
< > Goto Label 1#

6. das zweite Event mit diesem Code füllen:

Code:

< > Label 1#
< > Change Switch: Var[0001] Switch ON
< > If Var[0001:test]
  < > Play Sound Effekt:Blow5
  < >
:Else Case
 < > Change Switch: Var[0001] Switch ON
 < >
:End Case
< > Change Switch: Var[0001] Switch ON
< > Change Variable: Var[0001:zähler1] + 1
< > Goto Label 1#

Im ersten Event wird eine Variable auf 1 und nach mehreren Fülloperationen wieder auf null gesetzt. Das zweite Event überprüft während der Fülloperationen diese Variable. Und tatsächlich erkennt er die zwischenzeitliche Veränderung, was man an dem nervigen Dauerton sehr gut erkennen kann.

Mit F9 und den beiden Zähler-Variablen lässt sich das Geschwindigkeitsverhältnis der Events einsehen. Beide müssten genau gleich schnell laufen. Dadurch ist gewährleistet, dass die Fülloperationen des ersten Events und die If-Abfrage des zweiten Events gleichzeitig stattfinden.

OK, eins steht fest: Die Variablen werden wahrscheinlich global verarbeitet. Aber eine ganz andere Sache ist etwas merkwürdig:
Lässt man im Else-Teil die Switchänderung weg, wird das Event schneller durchgearbeitet. Befehle im Else-Teil einer Bedingung scheinen Rechenzeit zu beanspruchen, auch wenn der Else-Teil nicht aufgerufen wird.
(Fügt man im ersten Event und im Else-Teil des zweiten Events noch einmal ChangeSwitch ein, kommt kein Ton mehr; bei noch einem Befehl mehr, laufen die Events nicht mehr gleich schnell...)



CapSeb

[Nemica]

Du, jede Codezeile bremst den Maker, selbst Kommentare.

[makenshi]

Du, dein Versuch ist vielleicht nett gemeint.
Nur ist er so gesehen wertlos.
Deine erste Fehlvermutung ist das ein Makerbefehl lediglich einen Rechentakt benötigt. Wenn wir nun von der maschinennahen Sprache Assembler ausgehen, dann sieht man hier das für gewisse Operationen mehr als ein simpler Rechentakt benötigt wird. Und wir reden von eher "simplen" Dingen wie bspw. zwei Register voneinander abzuziehen.

Bei deinem Versuch, verarscht dich simpel und einfach die anscheinend gleichzeitige Verarbeitung. Der Maker wird wohl wie die meisten Programme seine Befehle nacheinander abarbeiten. Nur wird er das bei anscheinend parallelen Prozessen nach einen gewissen Muster tun. Wenn ich hierbei einfach mal von der Threadarbeitsweise ausgehe, dann dürfte zwischen den Befehlen immer wieder für gewisse Anzahl an Millisekunden umgeschaltet werden.
Das ganze passiert auf jeden Fall schnell genug um eine gewisse parallele Verarbeitung vorzutäuschen. Man sieht diesen Effekt recht gut wenn man versucht zu große PPs laufen zu lassen. Schon hat man den berühmten Ruckeleffekt wegen dem die Leute manchmal Wait 0.0 an ihre PPs hängen.

So wird die Wiederholung immerhin für diese Dimensionen um eine Ewigkeit verzögert.


Die nächste Fehlvermutung die schon logisch gesehen auffallen müsste, ist die Sache mit dem ELSE Case. Warum genau solltest du beim bauen eines Interpreters dir eine solche Geschwindigkeitsbremse einbauen?
Du baust diese Falltrennung ja immerhin dafür ein, das du gewisse Teile des Codes ausklammern kannst.
Deswegen ist es sicherlich völlig falsch direkt von Beanspruchung zu sprechen.

Augenscheinlich scheint der Maker alles Zeile für Zeile einzulesen. Ergo wird wohl markiert sein welche Teile zum ELSE CASE gehören und welche eben nicht. Diese werden zwar kurz gelesen, aber dann wohl einfach übersprungen. Immerhin ist die Funktion des Zweiges das eben dies geschehen soll. Genau so dürfte es sich bei den Kommentaren verhalten.

Ich würde an sich aber auch kaum weiter darüber nachdenken als es wirklich nötig ist. Wer sich mit den sichtbaren Makermechanismen auskennt, der wird auch keine Probleme beim zusammenklicken seiner Skripte haben.

Das einzige was hier momentan nämlich geschieht, sind Vermutungen. *schulterzuck*

[CapSeb]

Der Maker arbeitet anscheinend in einem Rechentakt immer einen Befehl pro parallel Event (wartet also wahrscheinlich diesen Takt lang bis alle Events einen Schritt weiter sind).

...

Deine erste Fehlvermutung ist das ein Makerbefehl lediglich einen Rechentakt benötigt. Wenn wir nun von der maschinennahen Sprache Assembler ausgehen, dann sieht man hier das für gewisse Operationen mehr als ein simpler Rechentakt benötigt wird. Und wir reden von eher "simplen" Dingen wie bspw. zwei Register voneinander abzuziehen.

...

Gut, ich meinte auch nicht die Prozessortaktung oder sowas, sondern eine vom Maker erzeugte Taktung. Wie ein Echtzeitkampf, der intern rundebasierend ist. Sonst wäre ein "Warten" auch nicht möglich (Switchänderungen, Variablen... dauernd gleich lang).

Das ganze passiert auf jeden Fall schnell genug um eine gewisse parallele Verarbeitung vorzutäuschen. Man sieht diesen Effekt recht gut wenn man versucht zu große PPs laufen zu lassen. Schon hat man den berühmten Ruckeleffekt wegen dem die Leute manchmal Wait 0.0 an ihre PPs hängen.

...

Der Maker ruckelt weil zwischen den Events hin- und hergeschaltet wird? Und warum nur bei großen PPs - bei kleineren muss er dann doch auch hin- und her schalten?!

Augenscheinlich scheint der Maker alles Zeile für Zeile einzulesen. Ergo wird wohl markiert sein welche Teile zum ELSE CASE gehören und welche eben nicht. Diese werden zwar kurz gelesen, aber dann wohl einfach übersprungen. Immerhin ist die Funktion des Zweiges das eben dies geschehen soll.

...

Hm, aber warum benötigt er dann für dieses Überprüfen des Elses so lange? Schließlich wartet er bei anderen Befehlen den besagten Takt.

Aber schonmal gut zu wissen, dass er springt.


CapSeb

[makenshi]

Der Maker ruckelt weil zwischen den Events hin- und hergeschaltet wird? Und warum nur bei großen PPs - bei kleineren muss er dann doch auch hin- und her schalten?!

...

Nein. Der Maker ruckelt nicht weil er zwischen Events hin- und herschalten muss. Jedenfalls nicht im Normalfall. Wenn zu viele performanceträchtige Befehle hintereinander ausgeführt werden müssen (wie z.B. Show Picture), dann braucht der Maker logischerweise länger um diese Befehle zu verarbeiten. Ergo kann er den Befehl nicht schnell genug zuende bearbeiten und zum nächsten Event schalten. Da trotzdem alles in seinen geordneten Wegen laufen muss, werden die Befehle trotzdem weiter bearbeitet. Es dauert nun länger bis "normal" weiter gearbeitet werden kann. Und halt auch bis zum nächsten Befehl umgeschaltet wird. Und schon bemerkst du diese Arbeit. Eben als Verzögerung.

Hm, aber warum benötigt er dann für dieses Überprüfen des Elses so lange? Schließlich wartet er bei anderen Befehlen den besagten Takt.

...

Das es für dich so lange dauert, liegt an deiner Messmethode.
Die für so etwas simpel nicht geeignet ist. Die einzige wirklich ernst zunehmende Möglichkeit um so etwas zu messen, ist es ein zweites Programm nebenbei mitlaufen zu lassen. Dieser kann dann genau im internen messen wie lange die Anwendung für bestimmte Vorgänge benötigt. Aber bestimmt nicht dadurch das du solche Messungen versuchst im Programm selbst vorzunehmen.
Bei den makerinternen Dingen wie bspw. den Bewegungsgeschwindigkeiten geht das wunderbar. Aber nicht bei so etwas. Das sieht man ja an deinen Messergebnissen.

Aber schonmal gut zu wissen, dass er springt.

...

Wie schon gesagt, es gibt ohne einen zweiten CPU Kern der andere Befehle bearbeiten kann kein echtes paralleles arbeiten. Das wird vom PC nur vorgetäuscht. An sich eher vom OS um genauer zu werden. Wenn dich diese Thematik so interessiert, dann solltest du dich einmal mit der Thread programmierung auseinandersetzen. Da erfährst du mehr über dieses Prinzip.

An sich aber brauchst du so etwas nicht wirklich für den Maker imo.
Da reicht an sich das grobe Wissen das parallele Prozesse "gleichzeitig"
arbeiten. Und natürlich wie die Eventaktivierung von statten geht.
Wer so etwas versteht, wird mit dem ganzen Eventsystem kein Problem haben.

[CapSeb]

Gut, danke! Das war doch recht aufschlussreich, nach der ganzen Verwirrung.
Ich werde mich wohl erstmal nicht weiter damit außeinander setzen. Denn:

An sich aber brauchst du so etwas nicht wirklich für den Maker imo.
Da reicht an sich das grobe Wissen das parallele Prozesse "gleichzeitig"
arbeiten. Und natürlich wie die Eventaktivierung von statten geht.
Wer so etwas versteht, wird mit dem ganzen Eventsystem kein Problem haben.

...

No problem. 8)


CapSeb