Druckbare Version
Hi Ho oder so,
mein RMXP ruckelt beim Testspielen zum Teil extrem. Ich weis das es wohl an der relativ großen Map liegt (90*50) und wahrscheinlich auch an den Events die darauf sind. Obwohl überall waits drin sind, ruckelt es auf meinem PC:
AthlonXP2 5200
2GB Ram
Geforce8800 GTS
:rolleyes:
Ich weis das es für den 2000er mal ein Script oder sowas gab, womit man die Performance verbessern konnte und wollte fragen ob es sowas ähnliches auch für den RMXP gibt? ._.
MFG
Ich denke hier hilft das Anti Lag Skript.
Die Mapgröße hat mit dem Ruckeln nix zu tun. Die Map kann auch 500*500 groß sein, ohne das es zu Performanceunterschieden kommt.
Dann liegt es schon eher an den Events. Wie viele hast du denn auf der Map? Bewegen die sich alle? Und du sprachst von Waits: Hast du viele parallele Prozesse laufen (btw. dürften waits im XP ohnehin nicht so wichtig sein)?
@Mani
Ja genau das hab ich gemeint. Vielen Dank. :)
@KD
207 Events die Meisten bewegen sich nicht und stellen nur grafische Elemente dar. Hab nur 3 Parallele Prozesse wobei 2 davon nur kurz bei Betritt der Map aktiviert werden.
Naja das Anti Lag Script hat Wunder gewirkt und die Lags sind weg. ^^
MFG
Wobei das anti-lag script meines Wissens nach alle aktuell nicht-sichtbaren Events deaktiviert, also kann das auch zu Problemen führen wenn Events die man grad nicht sieht, die aber auf der Map sind und eine Funktion erfüllen müssen.
207 Events die größtenteils grafische Elemente darstellen? Warum nutzt du nicht das Tileset dafür? Im XP darf das Tileset beliebig groß sein. Dessen Größe hat auch keinen spürbaren Einfluss auf die Perfomance. Dagegen sind 200 Events einfach zu viel für den XP.
Also die Eventgrafiken ins Tileset integrieren und wirklich nur noch da Events verwenden, wo die auch eine Funktion haben.
Bei mir ruckelt RMXP ebenfalls, schon seit ich ihn hab.
Eine Map ohne Events gibt mir ne Framerate von 2 bis 10 FPS (von 30), Antilag ändert auch nichts daran.
Das ist ja auch nicht normal. Was hast du denn für eine CPU? Pentium 2 oder wie? Kann's mir sonst nicht wirklich erklären...Zitat:
Zitat von MagicMaker
Im XP stehen Mindestanforderungen. Wenn ein PC diese einhält, dürfte der Maker auch ohne ruckeln laufen. Das jedes Spiel individuelle Anforderungen an die Hardware stellt, dürfte klar sein. Das ist im Rm2k nicht anders, nur dass dort die Anforderungen geringer sind. Aber der Rm2k hat ja auch schon einige Jahre auf dem Buckel. Ein aktueller PC dürfte mit dem XP keine Probleme haben.
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.
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.
@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...
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).
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.Zitat:
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.
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.
Ähem .. nein! Es ist möglich das Tileset groß zu gestalten, aber auch beim XP gibt es eine maximale Größe die ich aber jetzt nicht weiß. Jedoch hat die Größe des Tilesets großen Einfluss auf die Performance. Und zwar wenn ein Tilest ab einer Länge von ca. 13000 - 14000 Pixel zum Einsatz kommt, fängt es an zu laggen. Die Zeit zwischen dem Teleport auf andere Maps und den Menaufrufen erhöht sich deutlich! Und je größer das Tileset wird, desto länger dauert es. Deshalb rate ich von solchen Ideen ala "alle außentilsets" etc. auch dringends ab u.a. wegen dem Performanceproblem.Zitat:
Zitat von -KD-
greetz
Gut, soweit habe ich nicht getestet. Ich hatte damals nur bis 10.000 getestet, danach hat mein Photoshop gestreikt. Ich ging davon aus: wenn Photoshop nicht nicht mehr will, wird wohl kaum jemand sowas in den Maker integrieren wollen.
Das die Dauer für Menüaufruf und Mapwechsel zunimmt, stimmt. Ich bezog mich nur auf die Framerate.
Hat eigentlich schon mal jemand getestet was passiert, wenn man anstelle von png bmp benutzt?
Ich hoffe für dich, dass aus dir nur Unwissen spricht, besonders im letzten Teil.Zitat:
Zitat von Macavity
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.
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
@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.
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.Zitat:
Zitat von Ascare
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:
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.Zitat:
Zitat von Makerninja
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.
Zu dem Hardware-Rendering habe ich mal einen Post von Der Drake rausgekramt, da er mal was dazu geschrieben hatte:
Zitat:
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)
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.
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.Zitat:
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.
ika verlangt übrigens nur 266 Mhz und eine simple 3D-Grafikkarte.
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.Zitat:
Zitat von The_Burrito
greetz
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).
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
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?
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
@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.
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. :PZitat:
Zitat von $cHm0cK
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. ;)
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.
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%?
Auf einer 50x50 Map mit 20 animierten Events war auf meinem Rechner schon ein leichtes Ruckeln spürbar.Zitat:
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.
Wenn du an die Pictures denkst, welche du normal über Eventcommands anzeigst, dann vielleicht. Mit RGSS gibt es aber wesentlich elegantere Möglichkeiten.Zitat:
Zitat von Kyuu
Zum Beispiel? Wieso habe ich das Gefühl, dass wir an einander vorbeireden...Zitat:
Zitat von The_Burrito
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
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.
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.Zitat:
Zitat von Makerninja
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
Es macht keinen Unterschied, ob man ein Picture über ein Event-Befehl, oder über die API (RGSS) anzeigt, die verbrauchten Ressourcen sind identisch.Zitat:
Zitat von Makerninja
Du vergleichst hier Welten miteinander. Es ist ein enormer Unterschied, ob man die eingebettete Skriptsprache und die API verwendet, oder ob man von Grund auf eine neue Engine mit einer Hochsprache wie C++ programmiert. Und selbst wenn du dich an einer eigenen Engine versuchst, wirst du um eine Skriptsprache nicht herum kommen, weil eben der Sinn hinter dieser eine Erleichterung beim eigentlichen Game Development ist.Zitat:
Zitat von Makerninja
Eine Skriptsprache zu erlernen benötigt nicht viel, denn im Grunde musst du nur die Syntax einzusetzen wissen. Die Kommunikation zwischen Skript und Engine läuft sowieso über die API, so dass die API eigentlich das ist, womit du dich eine Zeit lang auseinandersetzen wirst.
Der Maker bietet so schon mehr Vereinfachung per Drag&Drop-Prinzip, als es irgendeine andere Engine tun würde, mehr geht in meinen Augen nicht.
Mit RGSS und Ruby hast du nun aber auch die Möglichkeit diese Vereinfachungen - die deine Möglichkeiten stark limitieren - zu umgehen und wie ein echter Spiele-Entwickler an die Sache heranzugehen.
Zweitens mag ja stimmen.
Aber erstens stimmt so gar nicht. Es macht schon einen Unterschied aus, ob ich ein KS in einem einzigen Rubyscript aufbaue oder ob ich das KS aus Events, mit zig paralellen Ereignissen und ganz vielen statischen (HP Zahlen etc) aufbaue. Das es afaik über Events fast unmöglich ist, sehe ich am KS eines Freundes. Bei ihm läuft der XP ruckelfrei, doch sein selbstgeskriptetes KS (mit Events) ruckelt wie die Sau (und er hat keine Fehler wie vergessene Waits oder ähnliches drin). Auf meinem Rechner läuft der XP serh schlecht, ein RubyKS wie z.B. das von Cybersam läuft aber selbst bei mir ruckelfrei.
Und das dürfte keine Ausnahme sein.
Ninja
Wieso stimmt ersteres nicht? Ich habe von reinem Picture-Anzeigen geredet.
Naja, dass viele Events den Maker in die Knie zwingen ist ja bekannt und wurde u.a. hier auch schon einige Posts oben von Kelven bestätigt. Die Schuld dafür trägt entweder schlechte Programmierung oder ein langsamer Ruby-Interpreter.
Wenn man die Anzahl der Events niedrig hält, ist sicher auch ein, nur auf Event-Commands aufbauendes KS möglich. Ich möchte auch offen halten, dass dein Freund womöglich auch nicht gerade effizient an die Sache rangegangen ist, Waits sind nicht das Einzige worauf man achten sollte.
Edit:
Gibt es eigentlich Geschwindigkeitsunterschiede in der Ausführung von Common Events und Map Events?
Es ist sein drittes KS, und nur weil er nicht im Internet bekannt ist, heißt das nicht, dass er zu doof ist ein KS zu proggen -.-* Sein KS reduziert schon alles auf ein Minimum um eine möglichst gute Leistung zu erzielen. Ruckeln tuts bei mir wie gesagt trotzdem, während diverse RubyKS einwandfrei und ruckelfrei laufen.
Wobei ich jetzt mal behaupte, dass auch der gute Lachsen kein (auf 1,6Ghz und 768MB Ram) 100% ruckelfreies eventbasiertes KS mit dem XP hinbekommen kann.
Ich verstehe nicht, warum du behauptest, dass RubyKampfsysteme genauso viel Leistung ziehen, wie eigene eventbasierende Kampfsysteme. Teste es doch einfach mal selber -.-*
Ninja
Zu deiner Frage: Ich glaube, das CommonEvents einen Tick schneller waren, lege dafür aber nicht meine Hand ins Feuer.
Map Events haben eine höhere Priorität, aber ich denke nicht, dass sich die Geschwindigkeit unterscheidet.Zitat:
Gibt es eigentlich Geschwindigkeitsunterschiede in der Ausführung von Common Events und Map Events?
@Makerninja
Wann bzw. bei was tritt denn das Ruckeln auf? Evtl. wird ja der Bildschirminhalt zu oft aktualisiert oder es wird unnötig viel Eventcode ausgeführt. Die Probleme, die ich im Menü mit dem laggen hatte, kamen alleine durch die Länge des Eventcodes (das Parsen der Befehle kostet halt auch Zeit). Dann könnte auch das rekursive Aufrufen der KS-Routinen Schwierigkeiten machen, so was wird ja oft in Maker-Kampfsystemen gemacht.
@Kelven:
Darum drehte sich mein Post eigentlich nicht. Ich wollte nur darauf hinweisen, dass eigene Kampfsystem (auch selbst gemachte oder ganz einfach gehaltene) bei mir ruckeln, während die RGSS-Scripte für Kampfsystem aus dem Netz, die in etwa das gleiche boten, ruckelfrei liefen.
Wenns bei dir nicht ruckelt: Glück gehabt, dann hast du einen guten Rechner.
Und das ewig lange Fork-Abfragen zu Rucklern (oder laggen -.-) führen können ist mir durchaus bewusst. Das hab ich schnell selber gemerkt.
Ninja
Hör auf zu pauschalisieren.Zitat:
Zitat von Makerninja
Ich habe nie behauptet, dass Ruby-Kampfsysteme gleiche Leistung bringen wie Event-Kampfsysteme, sondern nur dass es keinen Unterschied macht, ob man ein Picture in einem Event oder in einem Ruby-Skript anzeigt.
Daraus folgt nämlich, dass die Schuld für Performanceverluste bei Event-Kampfsystemen in der Menge (und wie Kelven sagte, in der Länge) der Events zu suchen ist, die so ein Kampfsystem verschlingt. Jedes Event auf einer Map muss durchlaufen und interpretiert werden, egal ob es nur Zahlen-Events oder sonst welche sind. Im Vergleich kommt ein Ruby-Kampfsystem mit vielleicht zwei, drei Skripten weg. Hinzu kommt noch, dass Event-Kampfsysteme auf Map-Events basieren, die natürlich die Map Engine voraussetzen und diese wiederum Ressourcen frisst.
Und ich behaupte immernoch, dass man ein Event-Kampfsystem auf die Beine stellen kann, das wenig Events verschlingt und flüssig läuft. Alles eine Sache der Optimierung.