RMXP ruckelt o_O

[Ascare]

@Kyuu
Warum soll das Unwissen sein was er sagt?

@S1Drano
Smooth Mode bewirkt ob ein Spiel mit 40 FPS oder 20 FPS läuft (je nachdem ob aktiviert). Das dein Spiel nur 12 bzw. 33 FPS schafft liegt entweder an deiner CPU oder an den eingebauten "Features" im Spiel (viele Events, ressourcenlastige Scripte usw.).
Du kannst zwar die Framerate hochschrauben aber das nützt nicht viel ausser das deine CPU sich noch mehr anstrengen muss um die FPS konstant zu halten.
"Reduce Screen Flickering" ist die anwenderfreundliche Umschreibung (ums mal positiv zu formulieren) für V-Sync. Wenn der an ist, zerrt das natürlich auch an der CPU Leistung.

[Kyuu]

@Kyuu
Warum soll das Unwissen sein was er sagt?

...

Zuerst mal steht es außer Frage, dass vieles beim Maker anders hätte gemacht werden können. Zum Beispiel: Anstatt nur auf software-basiertes Rendering zu setzen, hätten sie das Rendering-System abkapseln und als Optionen (software-/hardware-basiert) zur Verfügung stellen sollen (Siehe: Sphere). So hätte man die Möglichkeit auf hardware-basiertes Rendering umzusteigen, wenn man nun müsste wegen zu niedrigen FPS-Raten.
Der Vorteil von software-basiertem Rendering ist klar die Hardware-Unabhängigkeit, allerdings bezweifle ich, dass OpenGL jemals zu Problemen führen würde, da selbst sehr alte 3D-Grafikkarten OpenGL vollständig unterstützen.
Oder: Anstatt Ruby als Skriptsprache zu verwenden, hätten sie Python nehmen sollen, was viel mächtiger und in der Ausführung schneller ist als Ruby es je sein könnte.

Von Hochsprachen wie C++, etc. als Skriptsprache kann weiter überhaupt nicht die Rede sein, da diese sehr viel Erfahrung und Routine benötigen und nicht einfach nur schwieriger sind (das ist eh zu allgemein). Alleine das Memory Management und die damit verbundenen Probleme würden die meisten dazu veranlassen, den XP so schnell wie möglich zu deinstallieren. Da spielt es wirklich nur eine sehr geringe Rolle, wie lange es dauert, das Spiel zu kompilieren. Damit kommen wir nun auch zum Punkt der "stundenlangen Kompilierungszeiten", was wirklich sehr übertrieben ist, da selbst größere Programme, von mehreren MBs höchstens 10-15 Minuten dauern (zumindest meiner Erfahrung nach, und ich hatte schon mit durchaus großen Projekten zu tun) und ich glaube nicht, dass ein RPG-Maker Projekt jemals auch nur in die Nähe der Ausmaße dieser Programme reinkommt. Mal davon abgesehen, dass sowieso nicht alles kompiliert werden müsste, sondern im Grunde nur die Skriptdateien.
Wie gesagt, Python statt Ruby hätte dem ganzen schon einen großen Schub gegeben, wobei es aber nicht unbedingt Ruby ist, was den XP so langsam macht, da eine der größten Ursachen dafür eher in der Grafik-Engine liegt.

Ein wichtiger Punkt, wieso Interpretersprachen als Skriptsprachen verwendet werden ist übrigens, dass sie auf virtuellen Maschinen laufen und somit vollkommen vom System und der Hardware unabhängig sind, was bei Compiler-Sprachen ganz anders aussieht, da die Compiler Maschinencode für bestimmte Architektur erzeugen.

Ich bezweifle, dass das Team hinter dem RPG Maker XP sehr talentiert ist, zu vieles scheint mir sehr schlampig und undurchdacht umgesetzt worden.
Man siehe alleine was Sphere oder ika leisten und man möchte nie wieder zum RPG Maker XP(f) zurück.


EDIT:

Auch die Konsolen wie der SNES konnten mit viel weniger Mhz schöne 2D-Spiele darstellen - mit Mode7 und allem drum und dran.

...

Darauf würde ich das Argument bringen, dass Konsolenspiele sehr hardwarenah programmiert wurden, das heißt, es gibt kein OS dazwischen mit all seinen Routinen und Abläufen, die gleichzeitig und ständig laufen müssen und natürlich Ressourcen fressen.
Die Konsolensoftware greift also direkt auf die Hardware zu, was deutlich mehr Leistung bedeutet im Vergleich mit einer ähnliche Software auf einem PC mit ähnlicher Rechenleistung.

[Ascare]

Zu dem Hardware-Rendering habe ich mal einen Post von Der Drake rausgekramt, da er mal was dazu geschrieben hatte:

Der XP wird genaugenommen mit GDI gerendert, was auf den ersten Blick absolut hirnrissig ist. Auf der anderen Seite sehen viele bei dem Begriff "Hardware Beschleunigt" nur die Vorteile die das mit sich bringt. (enorme geschwindigkeit, CPU entlastung, etc.)
Wenn ich mir auf der anderen Seite die Ressourcen anschaue die einige XPler so erstellen, muss ich sagen, dass Hardware Beschleunigung ihnen sehr schnell einen Strich durch die Rechnung gemacht hätte. Ein Chipset mit den Maßen 256x38496 ist für eine Grafikkarte wie ein Buch mit sieben Siegeln.

Texturen (das heißt, Hardwarebeschleunigte Grafiken) müssen eine Größe von 2^n x 2^n haben, bei moderneren Karten auch 2^n x 2^m.
Um nun eine Grafik mit den Maßen 640x480 anzuzeigen, müsste man sie zuerst auf eine Zwischengrafik mit den Maßen 1024x512 bringen*, was die Anzahl der Pixel von 307200 auf 524288 erhöht, das heißt dein neues Bild hätte 217088 total unnötige Pixel!

Zusätzlich können Grafik Karten keine unendlich großen Texturen anzeigen, normalerweise sollte man keine Grafiken benutzen die größer als 1024x1024 pixel sind, und am besten sollte das ganze noch ein gutes Stück kleiner sein.

Und das waren nun bei weitem noch nicht alle technischen Einschränkungen. Sicher, es gibt hier und da Tricks um das zu umgehen, aber die Implementierung wird schnell sehr aufwändig, und komfortabler als Software Rendering wird es sowieso nie. Da der Maker aber dafür konzipiert ist einfach zu sein, hat Enterbrain sich wohl für Software Rendering entschieden, das keine dieser Einschränkungen hat.
Ich will sie zwar nicht verteidigen, die Performanz ist in meinen Augen immernoch schrecklich (Direct Draw wäre ähnlich komfortabel gewesen, aber immernoch viel schneller, wenn auch veraltet), aber das Programm an sich finde ich wirklich toll, und außerdem macht die Performanz auf aktuellen Rechnern schon praktisch keinen Unterschied mehr... und in ein paar Jahren wird das wohl überall so sein.

*)
Die offensichtliche Lösung wäre, das Bild in viele kleine Bilder aufzuteilen. (in diesem Fall könnte man es in 8 Bilder aufspalten, die exakt die Kriterien einer Graka erfüllen) Das klingt zwar sehr nett, aber wird leider das gesamte Geschehen verlangsamen. Ist mir jetzt zu viel Arbeit, zu erklären warum, aber das ist auch keine Lösung...
Eine Lösung wäre 2D Bin Packing, was extrem komplex wird wenn man einen möglichst optimalen Algorhytmus verwenden will. (was man auch tun sollte)

...

[Kyuu]

Ich kann mich Drake nicht anschließen, ika beispielsweise setzt komplett auf OpenGL und es limitiert die graphischen Möglichkeiten in keiner Weise. Im Gegenteil, alles was im XP möglich ist, ist in ika möglich und noch viel mehr.
Auf einfachen Maps sind selbst vierstellige FPS-Raten in ika keine Seltenheit.

und außerdem macht die Performanz auf aktuellen Rechnern schon praktisch keinen Unterschied mehr... und in ein paar Jahren wird das wohl überall so sein.

...

Alleine schon Unsinn in meinen Augen, da eine solch simple 2d-Grafik-Engine niemals so hohe Systemanforderungen stellen darf, und selbst heute, nach "ein paar Jahren" gibt es genügend User mit FPS-Problemen und die wird es auch nach weiteren "paar Jahren" geben, da bin ich mir absolut sicher.
ika verlangt übrigens nur 266 Mhz und eine simple 3D-Grafikkarte.

[schmoggi]

Was auch sehr hilft, ist wenn man die Priorität des Spielprozesses im Task-Manager erhöht. Dadurch läuft das Spiel viel flüssiger. Ich habe es allerdings noch nicht mit einer Map mit sehr vielen Events getestet.

...

Das stimmt durchaus (vor allem bei vielen Events auf ner großen Map) ... jedoch ist es keine Garantie, da es bei jedem Rechner unterschiedlich ist. Mal läuft es besser, gleich oder gar schlechter ... muss jeder für sich ausprobieren.

greetz

[Homei]

Bei mir ruckelts auch bei konstanten 40 fps. Wenn ich mit "Graphics.frame_rate = 60" die Framerate künstlich auf 60 fps erhöhe, läufts konstant mit 60 fps, es ruckelt logischerweise weniger, aber flüssig ist es immer noch nicht; es läuft einfach schneller. Und wenn ich die Framerate beispielsweise auf 90 erhöhe, läuft es bei mir mit konstanten 60 fps, etwa doppelt so schnell wie normal (40->90), aber nicht wirklich flüssig.

Gibt es nicht noch einen Kniff, um das flüssig hinzubekommen? Beim RPG Maker 2000 läuft es zum Beispiel viel flüssiger.

Und, wenn ihr es noch nicht gemerkt habt (an den konstanten hohen Frameraten), ich habe kein schwaches System (E6400, 3GB, X1600).

[schmoggi]

Leute mal im Ernst ... WAS macht ihr denn mit dem Maker, dass er ständig bei euch ruckelt ... nur die Schuld auf den XP schieben könnt ihr auch nicht machen. Da sitzt das Problem teils auch vor dem Monitor.

greetz

[Homei]

Ich glaube eher, du merkst einfach nicht, dass es ruckelt. Oder findest du es im Game so flüssig wie wenn du einen Film schaust?

[schmoggi]

Ich weiß ja nicht, was du anstellst aber bei mir läuft der Maker mit konstanten 40 fps Oo .. und da ruckelt nix!

Zeige ca. 40 und aufwärts Pictures gleichzeitig an, dann ruckelt es ... aber wer tut das schon.

greetz

[Ascare]

@Homei
Ich hab übrigens auch sehr ähnliche Rechnerdaten wie du und bei mir läuft er bei allen Frameraten konstant. Also hat das schon mehr mit deiner Software Konfiguration zu tun, denn deine Hardware ist mehr als ausreichend für den RMXP.

[Kyuu]

Zeige ca. 40 und aufwärts Pictures gleichzeitig an, dann ruckelt es ... aber wer tut das schon.

...

Jeder, der nicht auf die abgrundtief hässlichen Standard-Systeme des Makers zurückgreifen will? Bei jedem etwas komplexeren Menü/Kampfsystem kommen locker 40 Pics zusammen. :P

[Kelven]

Ach watt, doch nicht auf dem XP. Anders als bei dem 2K muss man den ganzen Text ja nicht mehr mit Bildern anzeigen. Solange das Menü sich nicht bewegt und nicht dynamisch ist reicht ein Hintergrundbild + ein oder mehrere Cursor aus, zumindest für mich.

[The_Burrito]

Das ist allerdings richtig. Mit RGSS lässt sich die anzahl der Sprites die gleichzeitig angezeigt werden müssen stark reduzieren. Immerhin braucht man jetzt keine 4 Pictures um einen animierten Schaden über dem Gegner anzuzeigen (wenn man von Schaden bis 9999 ausgeht). Außerdem braucht man die Pictures die vom Eventcommand gebraucht werden überhaupt nicht mehr. Ich habe derzeit noch gar nicht mehr als 1 einziges Pic auf einmal angezeigt. Von daher sehe ich es wie $cHm0cK. Wer braucht schon viele Pics auf einmal.

[Kyuu]

Ich meinte eher wirklich komplexere Systeme, wie z.B. ein Menü mit Animationen, Frames, mehreren Cursors, etc (alleine Velsarbors Menü würde sicher an die 20 Pics verbrauchen und da geht noch mehr in Richtung Animation :P ). Wenn man nicht auf die Standard-Systeme zurückgreift - und darunter fallen das KS-System, das Menü-System, das Animation-System, etc. - kommt man an einigen Stellen sicher über 40 und mehr Pics, besonders wenn die Systeme sich überlagern.
Aber ich gebe zu, nicht jeder wird sowas vorhaben und sich eher mit simpleren Systemen zufrieden geben. :D

Aber was ist mit größeren Maps? Stand ja schon öfters im Raum, dass größere Maps mit vielen Events den Maker in die Knie zwingen. Es gibt zwar dieses Anti-Lag-Skript, das ist allerdings nur bedingt einsetzbar, wenn man darauf verzichten kann, dass die Events außer Sichtweite parallel ablaufen.

(Wir gehen übrigens bei der Frage, was diejenigen mit dem Maker anstellen, dass er bei ihnen ruckelt, davon aus, dass sie keinen schwächeren Rechner besitzen, wie im Fall von Homei. Nur für den Fall, dass es untergegangen sein sollte. :P )

Edit:

Wie steht es eigentlich mit Optimierung beim XP? Wird ein Bild mit 0% Transparenz schneller gerendert als ein Bild mit teilweise 0% und teilweise 100% Transparenz und das wiederum schneller als ein Bild mit Transparenz zwischen 0% und 100%?

[Kelven]

Aber was ist mit größeren Maps? Stand ja schon öfters im Raum, dass größere Maps mit vielen Events den Maker in die Knie zwingen. Es gibt zwar dieses Anti-Lag-Skript, das ist allerdings nur bedingt einsetzbar, wenn man darauf verzichten kann, dass die Events außer Sichtweite parallel ablaufen.

...

Auf einer 50x50 Map mit 20 animierten Events war auf meinem Rechner schon ein leichtes Ruckeln spürbar.

[The_Burrito]

Ich meinte eher wirklich komplexere Systeme, wie z.B. ein Menü mit Animationen, Frames, mehreren Cursors, etc (alleine Velsarbors Menü würde sicher an die 20 Pics verbrauchen und da geht noch mehr in Richtung Animation :P ). Wenn man nicht auf die Standard-Systeme zurückgreift - und darunter fallen das KS-System, das Menü-System, das Animation-System, etc. - kommt man an einigen Stellen sicher über 40 und mehr Pics, besonders wenn die Systeme sich überlagern.
Aber ich gebe zu, nicht jeder wird sowas vorhaben und sich eher mit simpleren Systemen zufrieden geben.

...

Wenn du an die Pictures denkst, welche du normal über Eventcommands anzeigst, dann vielleicht. Mit RGSS gibt es aber wesentlich elegantere Möglichkeiten.

[Kyuu]

Wenn du an die Pictures denkst, welche du normal über Eventcommands anzeigst, dann vielleicht. Mit RGSS gibt es aber wesentlich elegantere Möglichkeiten.

...

Zum Beispiel? Wieso habe ich das Gefühl, dass wir an einander vorbeireden...

[Rosa Canina]

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

Das ist echt das größte Manko - und auch nur weil es anders nur ruckeln würde.

Ninja

[Kelven]

Ne, das stimmt nicht. Ich hab zu Anfang beim XP das Menü genauso wie beim 2K gemacht und es hat nicht stärker gelaggt als dort (geruckelt sowieso nicht). Beide Maker haben Probleme damit viele Pictures und Charsets zu aktualisieren, ich hatte im schlimmste Fall Wartezeiten von einer gefühlten Sekunde bis der Cursor weitersprang; wie gesagt auch auf dem 2k. Ich kann aber nur für ein normales Custom-Menü auf einer eigenen Map sprechen, keine Ahnung wie es mit einem HUD aussieht. Bei einem KS sollte man übrigens noch weniger Probleme haben, da dort weniger Grafiken aktualisiert werden müssen.

[schmoggi]

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

Das ist echt das größte Manko - und auch nur weil es anders nur ruckeln würde.

Ninja

...

Also das ist einfach nur falsch. Viele übertreiben es einfach mit ihrer "xp ruckelt, ohne rgss keine chance" Einstellung. Ich selbst habe ein HUD und ein eigenes SkillMenü mit Events aufgebaut und da ist wirklich nix am ruckeln! RGSS dient da wirklich nur als Hilfe und um diverse Sachen leichter umzusetzen. Z.B. läuft für mein HUD die Berechnung von HP und MP über 4 RGSS (2 für die Berechnung und 2 für die Anzeige der Balken) Zeilen in einem Parallel CE. Ist übersichtlicher, man könnte es aber genau so gut über Events machen. Das Skill Menü ist komplett mit Events gelöst.

Auch muss man nicht für jede kleine Sache gleich ein neues Picture haben und anzeigen lassen. Da ist auch der Ersteller gefragt, durchdachte Pictures zu erstellen und anzeigen zu lassen. Mit etwas Geschick kommt man da mit weniger als 40 pics (was ja schon an sich ziemlich viel ist) mit sicherheit zu Recht.

Außerdem, was heißt "beim XP"? Beim neuen VX ist es auch nicht gerade viel besser bzgl. Lagging, auch wenn die FPS jetzt bei 60 liegt.

greetz