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

[Ascare]

Ich beschäftige mich gerade mit dem XP Lag Problem und wie manche vielleicht wissen ist der Smooth Mode mit 40 fps ziemlich lagfrei (solange es konstant läuft). Wenn ich den Smooth Mode aber abschalte, sind es genau die Hälfte also 20 fps. Nun, 20 fps sind ja nicht wenig, moderne HD Filme sollen ja auf 24 fps laufen, aber warum ist der XP trotz 20 fps immer noch am laggen? Ich meine ich teste hier eine leere 20x15 Map mit Aluxes der einfach rumspaziert und trotz 20 fps ruckelt bzw. vibriert sein Chara beim gehen. Bei 40 fps oder mehr habe ich das Problem nicht, aber es muss doch auch möglich sein flüssige Bewegungen bei 20 fps hinzubekommen?

Mir ist dabei aufgefallen das es auch irgendwie mit dem Move Speed (bzw. move_speed) zu tun hat. Solange man langsam geht, z.B. ein Speed von 2, macht sich kein Lag am Chara bemerkbar, also auch nicht bei 20 fps.
Ich würde gerne den Wurm in dem System finden.

PS: Sinn ist einfach für den Spieler mit einer schwächeren CPU den RMXP ruckelfrei zu bekommen.

[Wulfgar]

Kurze Antwort:
Das Menschliche Gehirn benötigt mindestens 24 Bilder pro Sekunde um eine "Ruckelfrei" darstellung zu ermöglichen.
Dein beschriebener Testhat aber nur 20 Bilder pro Sekunde was dem Gehirn nicht ausreicht. Da der Hintergrund sich nicht ändert ruckelt nur die sich bewegende Figur.

[The Best Isaac]

Kurze Antwort:
Das Menschliche Gehirn benötigt mindestens 24 Bilder pro Sekunde um eine "Ruckelfrei" darstellung zu ermöglichen.
Dein beschriebener Testhat aber nur 20 Bilder pro Sekunde was dem Gehirn nicht ausreicht. Da der Hintergrund sich nicht ändert ruckelt nur die sich bewegende Figur.

...

Laut Wikipedia-Artikel schon mit 16-18 FPS. Der von Ascare erläuterte Sachverhalt hört sich für mich eher nach einem anderen Problem an. Bin leider kein XP-Fachmann und kann nicht wirklich etwas dazu sagen. Würde mich aber auch interessieren.

[Mario Ana]

PS: Sinn ist einfach für den Spieler mit einer schwächeren CPU den RMXP ruckelfrei zu bekommen.

...

Ich habe einen relativ starken PC mit 2,53 GH und trotzdem ruckelts bei mir ab und zu. Ich denke der Grund deswegen ist einfach das Ruby Script System. Hab' schon sehr oft gelesen das "Ruby" einfach langsamer läuft als vergleichbare Sprachen.

[-KD-]

Mit Ruby hat das wenig zu tun. Wir sprechen hier von einer simplen Spielmechanik. Die dafür notwendigen Berechnungen laufen in wenigen Mikrosekunden ab. Richtig ruckeln tut der Maker nur, wenn du zu viele Grafiken etc. anzeigen musst, und damit hat Ruby nichts zu tun. Zeitaufwendige Rubyprozesse gibt es in einem Makerspiel eher selten.
Ich denke auch mal, dass es einfach an der niedrigen Framerate liegt. Ich kann das allerdings auch nicht beurteilen. Ich hab solange einen veralteten PC gehabt, dass ich Ruckler optisch gar nicht mehr wahrnehme *g*

[Kyuu]

Benutzt der Maker Doppelpufferung? Ich könnte mir vorstellen, dass im smooth mode ein Doppelpuffer verwendet wird.

[Ascare]

Wieso habe ich das dumpfe Gefühl das niemand meinen Beitrag gelesen und verstanden hat. >_>

[Rina]

20 sind wenig. Aber was meinst du mit XP Lag Problem ^^ ?

[Corti]

Wieso habe ich das dumpfe Gefühl das niemand meinen Beitrag gelesen und verstanden hat. >_>

...

40 Frames = lagfree
20 Frames = laggy as Hell

Mögliche Erklärung:
40 laggt genau so, man siehts nur nicht wegen dem "Smooth Mode"

[Ascare]

Ja, also...nohchmal in aller Kürze:

Bei 20fps laggt es NICHT wenn der Char langsam geht (move speed 2). Es laggt aber wenn der Char schneller geht (move speed 5).

Meine Vermutung war das 20 fps eigentlich reichen müssten um eine flüssige Bewegung darzustellen (hat sich ja auch durch den langsamen Char bestätigt). Nun ist die Frage inwiefern der Move Speed mit dem laggen zusammenhängt und wie man da per Ruby möglichst eine bessere Lösung schafft, so das es auch bei einem Char mit Move Speed 5 nicht laggt.

[Kyuu]

Ich verstehe nicht wieso du dich an diesem move speed aufhängst, es ist doch logisch, dass je schneller Grafiken bewegt werden und gleichzeitig je langsamer die Bildwiederholung ist, desto mehr wird es auch laggen.
Durch das Mehr an 20 FPS und durch den zweiten Puffer im smooth mode wird das Ganze flüssiger angezeigt.

Wieso ich denke, dass im smooth mode ein zweiter (oder zumindest ein weiterer) Puffer verwendet wird? Weil Bezeichnungen wie "vsync" oder "smooth" in der Regel auf einen zweiten Puffer deuten.
Ich kann zur Zeit keine Tests mit dem XP durchführen und es ist schon lange her, dass ich mit dem Tool gearbeitet habe, also ist das was ich vermute reine Theorie basierend auf meiner Erfahrung mit Grafikprogrammierung.

[Whiz-zarD]

Ein zweiter Puffer hat aber nichts mit den Bildern pro Sekunde zu tun.
Beim Doublebuffer geht es darum, dass der Bildaufbau flüssiger abläuft.
Es werden 2 Bilder erzeugt, die übereinander liegen. Nach einer Zeit wird das erste ausgeblendet und dann sieht man das zweite Bild.
Beim diesem Umschalten entstehen Störungen, die aber durch die Synchronisation eines Monitors verschleiert werden. Darum auch der Zusammenhang mit vsync.

Ich denke einfach mal, dass, wenn man den smooth Modus deaktiviert, er nur jeden zweiten Frame anzeigt. Dadurch sehen die Animationen recht kantig aus. Spart aber somit Ressourcen.

Und selbst 15 FPS können flüssig aussehen. Ein Beispiel wären dafür die Videosequenzen von den PSX und PC Teilen von Final Fantasy (VII - IX und auch die Remakes).
Die Videos laufen mit 15 FPS und sehen dennoch flüssig aus.

[Kyuu]

Naja, die Bilder liegen sicher nicht übereinander. Zumindest beim Software Rendering funktioniert Doublebuffering so, dass immer abwechselnd in einen Buffer geschrieben wird und gleichzeitig aus dem anderen gelesen wird.
Sicher, mehrere Buffer dienen in erster Linie zur Beseitigung von Bildstörungen, ich habe aber zumindest mit Sphere schon oft beobachtet, dass bei Benutzung nur eines Buffers, sich der Charakter stellenweise, besonders beim Scrollen, ruckelartig bewegt.
Als ich den zweiten hinzugeschaltet habe, war die Bewegung wieder flüssig.
Vielleicht lag es auch an etwas anderem, ich kann nicht 100%-ig sagen, dass es am zweiten Buffer lag, die Vermutung liegt aber nahe.

Naja, im Endeffekt können wir alle nur spekulieren, es sei denn jemand hat den Quellcode, so dass man das Ganze analysieren kann.

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