RMXP ruckelt o_O

[Kyuu]

Ich finde es traurig, dass man im XP alles über RGSS lösen muss. So ganz normale Sachen wie KampfSysteme und Menüs kann man im XP, selbst wenn man wollte, gar nicht mehr ohne Ruby machen, weil er dann, wie besagt, sofort mit Ruckeln anfangen würde.

...

Es macht keinen Unterschied, ob man ein Picture über ein Event-Befehl, oder über die API (RGSS) anzeigt, die verbrauchten Ressourcen sind identisch.

Ich persönlich würde mir keinen Maker kaufen, für den ich extra noch eine Scriptsprache lernen muss. Da kann ich gleich zu einer echten Programmiersprache greifen.

...

Du vergleichst hier Welten miteinander. Es ist ein enormer Unterschied, ob man die eingebettete Skriptsprache und die API verwendet, oder ob man von Grund auf eine neue Engine mit einer Hochsprache wie C++ programmiert. Und selbst wenn du dich an einer eigenen Engine versuchst, wirst du um eine Skriptsprache nicht herum kommen, weil eben der Sinn hinter dieser eine Erleichterung beim eigentlichen Game Development ist.
Eine Skriptsprache zu erlernen benötigt nicht viel, denn im Grunde musst du nur die Syntax einzusetzen wissen. Die Kommunikation zwischen Skript und Engine läuft sowieso über die API, so dass die API eigentlich das ist, womit du dich eine Zeit lang auseinandersetzen wirst.
Der Maker bietet so schon mehr Vereinfachung per Drag&Drop-Prinzip, als es irgendeine andere Engine tun würde, mehr geht in meinen Augen nicht.
Mit RGSS und Ruby hast du nun aber auch die Möglichkeit diese Vereinfachungen - die deine Möglichkeiten stark limitieren - zu umgehen und wie ein echter Spiele-Entwickler an die Sache heranzugehen.

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