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 (http://de.wikipedia.org/wiki/Bildfrequenz) 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" (http://npshare.de/files/36/4441/Ruckel%20Muckel.zip)
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. :D
- 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. :eek:

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

[The Alucard]

Vllt. liegt es auch einfach daran, dass das menschliche Auge 24 Bilder pro Sekunde erfassen kann. Ab 25+ täuscht das Auge eine fließende Bewegung vor. (wird beim Fernsehn genutzt) Dann macht euch mal einen Reim darauf, was der Post mitm Thread zu tun hat :D

[Whiz-zarD]

(wird beim Fernsehn genutzt)

Das hat aber nichts mit den Augen zu tun.
Der Ursprung der 25 Bilder pro Sekunde liegt wo anders.
Erstmal zeigt ein Fernseher keine 25 Bilder pro Sekunde, sondern 50 Halbbilder pro Sekunde. (Stichwort: Interlace)
In Ländern, die NTSC Besitzen sind es sogar 60 Halbbilder pro Sekunde.
Der Ursprung liegt jeweiligen Stromnetz des Landes.
Europa (PAL) besitzt ein Stromnetz mit einer Frequenz von 50 Hz. (50 Schwingungen pro Sekunde).
z.B. USA und Japan (NTSC) besitzen ein Stromnetz mit 60 Hz.
Beim BAS Signal (Das Schwarz/Weiss Signal) wurde damals die Frequenz das Stromnetzes für die Synchronisation benutzt.
Beim heutigen FBAS Signal wurde lediglich ein Farbsignal beim Schwarz/weiss Signal hinzugefügt.