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.Zitat von Wulfgar
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.
--
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*
Benutzt der Maker Doppelpufferung? Ich könnte mir vorstellen, dass im smooth mode ein Doppelpuffer verwendet wird.
Wieso habe ich das dumpfe Gefühl das niemand meinen Beitrag gelesen und verstanden hat. >_>
--
20 sind wenig. Aber was meinst du mit XP Lag Problem ^^ ?
40 Frames = lagfree
20 Frames = laggy as Hell
Mögliche Erklärung:
40 laggt genau so, man siehts nur nicht wegen dem "Smooth Mode"
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
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.
--
Geändert von Ascare (31.01.2008 um 11:27 Uhr)
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.
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.
--
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.
Geändert von Kyuu (31.01.2008 um 14:25 Uhr)
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:
--
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.
Geändert von Kyuu (01.02.2008 um 17:33 Uhr)
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.
--
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
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.
Berechtigungen
Zitieren
