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
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
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%?
Geändert von Kyuu (04.02.2008 um 10:34 Uhr)
Auf einer 50x50 Map mit 20 animierten Events war auf meinem Rechner schon ein leichtes Ruckeln spürbar.Zitat
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
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
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.
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.
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 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
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!