RMXP ruckelt o_O

[Rosa Canina]

Anforderungen vom XP sind Horror.
Meine 1,6Ghz-Kiste mit fast 1GB Ram schafft im XP-Maker kaum eine 20x15 Map - ohne paralelle Prozesse oder Events. Nur mit reinem Mapping ruckelt die schon leicht.

Meiner Meinung nach sind Anforderungen wie 1- 2GHz (so stehts z.B. beim VX in den Anforderungen) wirklich vollkommen überzogen. Ist Enterbrain echt zu doof eine simple 2D-Engine für den Maker zu proggen? Ich meine: Einige 2D-Games bieten klasse Effekte (Das BeatemUp MindArms z.B.) und laufen auf viel schlechteren Möhren. Auch die Konsolen wie der SNES konnten mit viel weniger Mhz schöne 2D-Spiele darstellen - mit Mode7 und allem drum und dran.

Aber back to Topic.
Tower, du hättest die Map ja auch unterteilen können.

[Ascare]

Es kommt eigentlich nicht so sehr auf die Ghz an, sondern auf die verwendete CPU bzw. dessen Kern. 1,6 Ghz mit Celeron oder Core2Duo ist ein immenser Unterschied.

[Rosa Canina]

@Ascare:
Ich hab nen simplen 1-Kern-PC, aber kein Celeron. Da der XP ja jetzt auch schon ein paar Jährchen auf dem Buckel hat, könnte man eigentlich vorraussetzen, dass er wenigstens ansatzweise darauf läuft. Also ehrlich, Enterbrain hat nichts gutes bislang verzapft. Ich wünsche mir wieder ASCII her...

[Ascare]

Falls du nicht weiß was für einen Prozessor du genau hast, kannst mal dieses Prog. benutzen: CPU-Z.
Es bietet dir alle relevanten Daten.
Und ob der Maker schon ein paar jahre auf dem Buckel hat ist ja egal, denn die Anforderungen an die CPU bleiben ja gleich. Die Mindestanforderungen von EB (PIII 800 Mhz) halte ich soundso für untertrieben. Meiner Erfahrung nach sollte es am Besten mindestens ein Zweikern Prozessor der neueren Generation sein (athlon x2/c2duo).

Und was ASCII betrifft, so ist das doch nur der Publisher. Die Entwicklercrew ist ja gleich geblieben. Es hat ja nur der Publisher gewechselt (nämlich zu Enterbrain).

[Macavity]

Ist Enterbrain echt zu doof eine simple 2D-Engine für den Maker zu proggen? Ich meine: Einige 2D-Games bieten klasse Effekte (Das BeatemUp MindArms z.B.) und laufen auf viel schlechteren Möhren. Auch die Konsolen wie der SNES konnten mit viel weniger Mhz schöne 2D-Spiele darstellen - mit Mode7 und allem drum und dran.

...

Das kann man doch nicht vergleichen, Da der RPG Maker auf sehr viel Dynamik und sehr wenig Kompilieren setzt ist das Ergebnis eine lustige Mischung aus zur Laufzeit generiertem und vorgenerierten Inhalten.
Nachdem man sich Ruby für den Hintergrund ausgesucht hat ist das Ganze logischerweise deutlich lahmer, aber wem wäre es lieber gewesen wenn Enterbrain auf C++ gesetzt hätte? Niemand, dann wäre es zwar deutlich schneller aber auch viel schwerer zu lernen.
Dazu kommt das eine Kompilierung eines größeren Programmes schon mal eine gute Weile dauern kann, ich weiß nicht wieviele davon begeistert wären wenn beim Export des Spieles der Rechner für ein paar Stunden ausgelastet ist.

[Kyuu]

Das kann man doch nicht vergleichen, Da der RPG Maker auf sehr viel Dynamik und sehr wenig Kompilieren setzt ist das Ergebnis eine lustige Mischung aus zur Laufzeit generiertem und vorgenerierten Inhalten.
Nachdem man sich Ruby für den Hintergrund ausgesucht hat ist das Ganze logischerweise deutlich lahmer, aber wem wäre es lieber gewesen wenn Enterbrain auf C++ gesetzt hätte? Niemand, dann wäre es zwar deutlich schneller aber auch viel schwerer zu lernen.
Dazu kommt das eine Kompilierung eines größeren Programmes schon mal eine gute Weile dauern kann, ich weiß nicht wieviele davon begeistert wären wenn beim Export des Spieles der Rechner für ein paar Stunden ausgelastet ist.

...

Ich hoffe für dich, dass aus dir nur Unwissen spricht, besonders im letzten Teil.

[The_Burrito]

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.

[S1Drano]

Ich würde die Finger lassen von Prioritäten. Wenn RmXP eine zu hohe Priorität hat, dann haben womöglich andere wichtige Module eine zu niedrige Priorität (Beispielsweise DirectX, was bei einigen Games stärkere Ruckler bewirkt, als man beheben möchte).

Ich würde auf F1 drücken und dann "Reduce Screen Flickering" deaktivieren und "Smooth Mode" aktivieren ("Smooth Mode" hat meine FPS von 12 auf 33 erhöht. Warum? Weiss ich nicht). Vielleicht gibt's nen Script, um diese Optionen standartmässig so eingestellt zu behalten (bei mir sind diese Optionen bereits Standart)

PS: Mein PC:
P4 2GHz
1GB RAM
Radeon X1950 Pro (AGP 4x)

Meine Map:
Grösse 25*20
Tileset RTP
Events 5 (4 bewegte Events mit animierter Grafik + 1 unsichtbares Event, nur aktiv um eine einzige Nachricht anzuzeigen)


Edit: Ich habe weiter getestet. Ich konnte meine Framerate von 33 sogar bis auf 55 erhöhen (Die FPS waren jedoch äusserst instabil: 15-55 FPS mit einem Durchschnitt von etwa 38-39 FPS). Ich habe beim Scripteditor unter "Main" folgenden Eintrag hinzugefügt: "Graphics.frame_rate = 60" gleich nach dem Eintrag "begin". Ohne diesen Eintrag erreiche ich 20-33 FPS mit Durchschnitt von 32-33 FPS. Der Wert muss nicht unbedingt 60 betragen, aber ich habe weder Zeit noch Lust, alle Werte durchzutesten

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