RMXP ruckelt o_O

[Rosa Canina]

Zweitens mag ja stimmen.

Aber erstens stimmt so gar nicht. Es macht schon einen Unterschied aus, ob ich ein KS in einem einzigen Rubyscript aufbaue oder ob ich das KS aus Events, mit zig paralellen Ereignissen und ganz vielen statischen (HP Zahlen etc) aufbaue. Das es afaik über Events fast unmöglich ist, sehe ich am KS eines Freundes. Bei ihm läuft der XP ruckelfrei, doch sein selbstgeskriptetes KS (mit Events) ruckelt wie die Sau (und er hat keine Fehler wie vergessene Waits oder ähnliches drin). Auf meinem Rechner läuft der XP serh schlecht, ein RubyKS wie z.B. das von Cybersam läuft aber selbst bei mir ruckelfrei.

Und das dürfte keine Ausnahme sein.

Ninja

[Kyuu]

Wieso stimmt ersteres nicht? Ich habe von reinem Picture-Anzeigen geredet.
Naja, dass viele Events den Maker in die Knie zwingen ist ja bekannt und wurde u.a. hier auch schon einige Posts oben von Kelven bestätigt. Die Schuld dafür trägt entweder schlechte Programmierung oder ein langsamer Ruby-Interpreter.
Wenn man die Anzahl der Events niedrig hält, ist sicher auch ein, nur auf Event-Commands aufbauendes KS möglich. Ich möchte auch offen halten, dass dein Freund womöglich auch nicht gerade effizient an die Sache rangegangen ist, Waits sind nicht das Einzige worauf man achten sollte.

Edit:

Gibt es eigentlich Geschwindigkeitsunterschiede in der Ausführung von Common Events und Map Events?

[Rosa Canina]

Es ist sein drittes KS, und nur weil er nicht im Internet bekannt ist, heißt das nicht, dass er zu doof ist ein KS zu proggen -.-* Sein KS reduziert schon alles auf ein Minimum um eine möglichst gute Leistung zu erzielen. Ruckeln tuts bei mir wie gesagt trotzdem, während diverse RubyKS einwandfrei und ruckelfrei laufen.

Wobei ich jetzt mal behaupte, dass auch der gute Lachsen kein (auf 1,6Ghz und 768MB Ram) 100% ruckelfreies eventbasiertes KS mit dem XP hinbekommen kann.

Ich verstehe nicht, warum du behauptest, dass RubyKampfsysteme genauso viel Leistung ziehen, wie eigene eventbasierende Kampfsysteme. Teste es doch einfach mal selber -.-*

Ninja

Zu deiner Frage: Ich glaube, das CommonEvents einen Tick schneller waren, lege dafür aber nicht meine Hand ins Feuer.

[Kelven]

Gibt es eigentlich Geschwindigkeitsunterschiede in der Ausführung von Common Events und Map Events?

...

Map Events haben eine höhere Priorität, aber ich denke nicht, dass sich die Geschwindigkeit unterscheidet.

@Makerninja
Wann bzw. bei was tritt denn das Ruckeln auf? Evtl. wird ja der Bildschirminhalt zu oft aktualisiert oder es wird unnötig viel Eventcode ausgeführt. Die Probleme, die ich im Menü mit dem laggen hatte, kamen alleine durch die Länge des Eventcodes (das Parsen der Befehle kostet halt auch Zeit). Dann könnte auch das rekursive Aufrufen der KS-Routinen Schwierigkeiten machen, so was wird ja oft in Maker-Kampfsystemen gemacht.

[Rosa Canina]

@Kelven:
Darum drehte sich mein Post eigentlich nicht. Ich wollte nur darauf hinweisen, dass eigene Kampfsystem (auch selbst gemachte oder ganz einfach gehaltene) bei mir ruckeln, während die RGSS-Scripte für Kampfsystem aus dem Netz, die in etwa das gleiche boten, ruckelfrei liefen.

Wenns bei dir nicht ruckelt: Glück gehabt, dann hast du einen guten Rechner.

Und das ewig lange Fork-Abfragen zu Rucklern (oder laggen -.-) führen können ist mir durchaus bewusst. Das hab ich schnell selber gemerkt.


Ninja

[Kyuu]

Ich verstehe nicht, warum du behauptest, dass RubyKampfsysteme genauso viel Leistung ziehen, wie eigene eventbasierende Kampfsysteme. Teste es doch einfach mal selber -.-*

...

Hör auf zu pauschalisieren.
Ich habe nie behauptet, dass Ruby-Kampfsysteme gleiche Leistung bringen wie Event-Kampfsysteme, sondern nur dass es keinen Unterschied macht, ob man ein Picture in einem Event oder in einem Ruby-Skript anzeigt.
Daraus folgt nämlich, dass die Schuld für Performanceverluste bei Event-Kampfsystemen in der Menge (und wie Kelven sagte, in der Länge) der Events zu suchen ist, die so ein Kampfsystem verschlingt. Jedes Event auf einer Map muss durchlaufen und interpretiert werden, egal ob es nur Zahlen-Events oder sonst welche sind. Im Vergleich kommt ein Ruby-Kampfsystem mit vielleicht zwei, drei Skripten weg. Hinzu kommt noch, dass Event-Kampfsysteme auf Map-Events basieren, die natürlich die Map Engine voraussetzen und diese wiederum Ressourcen frisst.
Und ich behaupte immernoch, dass man ein Event-Kampfsystem auf die Beine stellen kann, das wenig Events verschlingt und flüssig läuft. Alles eine Sache der Optimierung.