Warum reichen 20 fps nicht für ein ruckelfreies Spiel?

[Ascare]

Ich glaube ich habe jetzt das Problem ausfindig gemacht, naja eigentlich auch nur Spekulation: Der Chara wird jeden Frame neu gerendert. Und wenn er sich langsam bewegt sieht man das laggen nicht, weil er länger auf einer Position beharrt und diese dann mehrmals an der gleichen Position gerendert wird.
Dies kommt mir nicht effektiv vor und ist leider gar nicht per Ruby veränderbar.

Der Maker muss doch nicht jeden Frame des Chars 20 mal in der Sekunde neu rendern, oder doch? Hätte es nicht gereicht den schon vorhandenen Char der vorgespeichert ist einfach um 1 Pixel zu verschieben?
Ich mein, wenn man mit nem Chara ein Schritt nach rechts macht, dauert es vielleicht 1 Sekunde und in dieser Zeit wird der Chara 20 bis 40 Mal neu gezeichnet. Dies ist doch übertrieben häufig?
Leider ist das Graphics Modul verborgen und man kann nur raten ob man mit Modifikationen da bessere Ergebnisse bekommen hätte, z.B. den Chara nur neu rendern wenn er sich auch tatsächlich seine Grafik ändert wie bei einem neuen Schritt, einer anderen Blickrichtung oder einem anderen Actor Graphic.
Dann müsste ein Chara der einen Schritt nach rechts geht nur 3 Mal gerendert werden (Standpose, rechtes Bein vorn, linkes Bein vorn) anstatt wie jetzt mindestens 20 Mal.

Ach und zu Kyuu noch was aus der Doku des Makers:

Graphics.frame_rate
In [Smooth Mode], the number of times the screen is refreshed per second. The larger the value, the more CPU power is required. Normally set at 40. When not in [Smooth Mode], the refresh rate is halved, and graphics are drawn in every other frame.

...

[Kyuu]

Ich glaube ich habe jetzt das Problem ausfindig gemacht, naja eigentlich auch nur Spekulation: Der Chara wird jeden Frame neu gerendert. Und wenn er sich langsam bewegt sieht man das laggen nicht, weil er länger auf einer Position beharrt und diese dann mehrmals an der gleichen Position gerendert wird.
Dies kommt mir nicht effektiv vor und ist leider gar nicht per Ruby veränderbar.

Der Maker muss doch nicht jeden Frame des Chars 20 mal in der Sekunde neu rendern, oder doch? Hätte es nicht gereicht den schon vorhandenen Char der vorgespeichert ist einfach um 1 Pixel zu verschieben?
Ich mein, wenn man mit nem Chara ein Schritt nach rechts macht, dauert es vielleicht 1 Sekunde und in dieser Zeit wird der Chara 20 bis 40 Mal neu gezeichnet. Dies ist doch übertrieben häufig?
Leider ist das Graphics Modul verborgen und man kann nur raten ob man mit Modifikationen da bessere Ergebnisse bekommen hätte, z.B. den Chara nur neu rendern wenn er sich auch tatsächlich seine Grafik ändert wie bei einem neuen Schritt, einer anderen Blickrichtung oder einem anderen Actor Graphic.
Dann müsste ein Chara der einen Schritt nach rechts geht nur 3 Mal gerendert werden (Standpose, rechtes Bein vorn, linkes Bein vorn) anstatt wie jetzt mindestens 20 Mal.

...

Selbstverständlich muss jede Grafik jeden Frame neu in den Buffer geschrieben werden. Grafiken sind nur Pixel-Daten und wenn man eine Grafik rendert, kopiert man diese Pixel-Daten in den Buffer, wobei alle im Buffer vorhandenen Pixel-Daten, die sich unter der Grafik befinden würden, nach einem Algorithmus mit den Pixel-Daten der Grafik gemischt werden (oder wenn die Grafik solide ist, einfach überschrieben).

Das ist übrigens auch der Punkt der mich am meisten beim XP stört: dass das Rendering fest im System integriert ist. Hätten sie es abgekapselt und als Plug-In-System integriert, könnten wir eigene Grafik-Treiber schreiben.

[Whiz-zarD]

Das Bild wird sogar mehr als nur 40 mal pro sekunde neu gerendert
Wenn du ein CRT Monitor mit 100 Hz hast, dann wird das Bild 100 mal in der Sekunde neu aufgebaut.
Nur davon bekommt der eigentliche Teil der Grafikkarte nicht mit. Das passiert im RAMDAC, der auf der Grafikkarte sitzt.

[Abt Ploutôn]

Hallo,
ich denke das hängt auch damit zusammen, dass er weniger Zeit hat, also wenn die Geschwindigkeit 2 ist, hat er ja für das bewegen von einem Feld 14 Graphics.updates Zeit, wenn die Geschwindigkeit aber nun 5 ist, werden daraus 8 und da springt er vielleicht ehr, weil er ja für die gleiche Strecke weniger Zeit hat
Meine Vermutung, bin aber auch kein Experte auf dem Gebiet.

Gruß Sven

[RPG-UNLIMITED]

Ja, Abt hat recht, bei mir fängt es auch an zu laggen wen ich z.B ne große Map mit vielen Events mache und wen ich da noch die Geschwindigkeit von meinem Chara. dann bin ich Schnecken speed.

Mein pc ist auch schnell Intel Cuo Prozessor mit jewalls 1,5 Ghz.

Alo....liegt auch an der map.
Events verlangsamen es immer, wen es mehr als 10 Stück sind, es reicht schon wen sie nur mal einen Sxchatten oder nur eine Blume machen soll.
Sowas brermmst die map ab.

[schmoggi]

Manche machen, wie gesagt, einfach etwas falsch ... auch du RPG-Unlimited.

Die Map größe hat außerdem relativ wenig mit der Performance zu tun. Ausschlaggebend sind die Events, und ihre Einstellunge (laufen sie, animiert etc.)

80 Events, mit highspeed auf random ... die flitzen über die Map und die FPS bleibt auf 40. Bei mir ruckelt garnix. Und die Mapgröße hat da wirklich keinen Einfluss .. ob 500 x 500, oder 50 x 50. Performance bleibt konstant. Und je mehr Events im Bild sichtbar sind, desto mehr Leistung wird benötigt. Aber wie gesagt ... ruckelt nix.

Cpu ist ein A64 4200+ x2@ 5000+
2 GB Ram

greetz

[Expresseon]

Fakt ist, dass auf eine große Map mehr Event passen. Deshalb ruckelt es da auch schneller (logisch, was ^^). Das sollte man mal verstehen. Ansonsten biete ich das hier an:

DOWNLOAD "Ruckel Muckel"
Zwei Maps. Bitte FPS-Anzeige einstellen und nach dem Tranfer am Baumstumpf vergleichen. Unterschied festgestellt? Bescheid sagen.

[schmoggi]

Gibt keinen Unterschied .. wieso auch?

Klar passen auf ner größeren Map auch mehr Events ... aber mal ehrlich. Ich kann mir kaum vorstellen, das es Leute gibt die mehr als 100 Events auf einer Map haben ... außer man hat ne ziemlich große map mit mehreren städten darauf .... sehr unwarscheinlich und auch unüberischtlich! Ich frag mich sowieso, wie manche auf die mMn lustige Idee kommen, so große Maps erstellen zu wollen ... teilt man sich das einfach in kleinere Abschnitte und gut ist.

greetz

[Expresseon]

Eben das mein ich. Sein Projekt bekommt man ganz einfach flüssig:
- Nur 20*15 Maps verwenden.
Man setze ggf. größere Gebiete zusammen. Kann man auch als Strukturvereinheitlichung ansehen. So spart man automatisch Events ein, weil dann ja höchstens für 300 davon Platz ist.
- Events geschickt benutzen, anstatt die Map damit vollzuknallen.
Parallele Prozesse sollten grundsätzlich vermieden werden, der Begriff selbst sagt aus, was passieren kann. Noch schlimmer Autoruns. Besser ist es, Common Events einzusetzen um gleichartige Befehlsfolgen übergreifen einsetzen zu können.
- Keine Anti-Lag-Skripte verwenden.
Die Dinger bringen absolut nichts, bzw. kommt es darauf an: meist liegt hier die Einzelberechnung von 20*15-Ausschnitten einer Map eingesetzt, was aber auch fatale Folgen haben kann, da immer der Effekt erzielt wird und so flüssige Maps zum Ruckeln gebracht werden.
- Ruby statt Eventcode.
Mit der Skriptsprache regelt man alles übersichtlicher und effizienter, auch so spart man Ressourcen.
So mach ich das, und es klappt. Siehe da.

[schmoggi]

- Nur 20*15 Maps verwenden.

...

So sparsam muss man auch nicht sein ... 25 x 25 - 100 x 100 Maps sind mMn vollkommen ausreichend.

greetz

[-KD-]

Nach meinen Beobachtungen ist die Mapgröße auch völlig egal. Grafiken außerhalb eines Viewports kosten kaum zusätzliche Rechenzeit. Wichtig sind natürlich Mapelemente die selbst dann noch Rechenzeit kosten, wenn sie sich nicht im Einflussbereich des Spielers befinden. Das trifft eigentlich nur auf Events zu. Autostartevents würde ich jetzt nicht gerade als schlimmes Beispiel nennen. Die sind eigentlich recht harmlos und werden ohnehin nur für Zwischensequenzen oder Eventmenüs gebraucht. Sie sind zumindest weniger aufwändig wie CommonEvents oder Parallele Prozesse. Aber woran es meistens scheitert sind dutzende NPCs, Schmetterlinge, Vögel, irgendwelche Kisten die man als Events platziert obwohl sie auch ins Tileset gekonnt hätten usw. Tiere lassen sich imo besser per Ruby scripten. Bei NPCs ist das schon schwieriger. Hier muss man sich wohl einfach etwas einschränken.

[Ascare]

Das Thema dreht sich nicht darum wie man RMXP ruckelfrei oder ressourcenschonend zum Laufen kriegt, sondern warum es bei oder bessergesagt trotz 20fps so ruckelt.

[Macros]

Wichtig sind natürlich Mapelemente die selbst dann noch Rechenzeit kosten, wenn sie sich nicht im Einflussbereich des Spielers befinden. Das trifft eigentlich nur auf Events zu. Autostartevents würde ich jetzt nicht gerade als schlimmes Beispiel nennen. [...]Sie sind zumindest weniger aufwändig wie CommonEvents oder Parallele Prozesse. Aber woran es meistens scheitert sind dutzende NPCs, Schmetterlinge, Vögel, irgendwelche Kisten die man als Events platziert obwohl sie auch ins Tileset gekonnt hätten usw. Tiere lassen sich imo besser per Ruby scripten. Bei NPCs ist das schon schwieriger. Hier muss man sich wohl einfach etwas einschränken.

...

Wenn man ein Anti-Lag-Script benutzt ist es auch kein Problem eine große Map mit über hundert Events zu betreten. Das Script führt dazu, dass Events die nicht im Sichtbereich sind nicht berechnet werden, das gilt auch für Events mit parallelen Prozessen. Einige Scripts unterstützen es auch eine Notiz ins Event zu schreiben damit es trotzdem, falls dies nötig ist dauerhaft berechnet wird. Ich habe damit nur positive Erfahrungen gemacht und der Nutzen lässt sich ganz einfach an einer Demo demonstrieren. Von daher kann ich auch die Kritik von PX nicht nachvollziehen.
Eine Frage hätte ich allerdings noch zu dem was du gesagt hast: Wie soll man denn Tiere in Ruby schreiben? Also ich kann ihre Reaktion in Ruby schreiben und das in ein Event einfügen, aber ich muss ja trotzdem das Event setzen - gut man könnte auch die Grafik mit Ruby anzeigen lassen, aber das kommt mir arg umständlich vor.