Druckbare Version
Gibt keinen Unterschied .. wieso auch?
Klar passen auf ner größeren Map auch mehr Events ... aber mal ehrlich. Ich kann mir kaum vorstellen, das es Leute gibt die mehr als 100 Events auf einer Map haben ... außer man hat ne ziemlich große map mit mehreren städten darauf .... sehr unwarscheinlich und auch unüberischtlich! Ich frag mich sowieso, wie manche auf die mMn lustige Idee kommen, so große Maps erstellen zu wollen ... teilt man sich das einfach in kleinere Abschnitte und gut ist.
greetz
Eben das mein ich. Sein Projekt bekommt man ganz einfach flüssig:
- Nur 20*15 Maps verwenden.
Man setze ggf. größere Gebiete zusammen. Kann man auch als Strukturvereinheitlichung ansehen. So spart man automatisch Events ein, weil dann ja höchstens für 300 davon Platz ist. :D
- Events geschickt benutzen, anstatt die Map damit vollzuknallen.
Parallele Prozesse sollten grundsätzlich vermieden werden, der Begriff selbst sagt aus, was passieren kann. Noch schlimmer Autoruns. Besser ist es, Common Events einzusetzen um gleichartige Befehlsfolgen übergreifen einsetzen zu können.
- Keine Anti-Lag-Skripte verwenden.
Die Dinger bringen absolut nichts, bzw. kommt es darauf an: meist liegt hier die Einzelberechnung von 20*15-Ausschnitten einer Map eingesetzt, was aber auch fatale Folgen haben kann, da immer der Effekt erzielt wird und so flüssige Maps zum Ruckeln gebracht werden.
- Ruby statt Eventcode.
Mit der Skriptsprache regelt man alles übersichtlicher und effizienter, auch so spart man Ressourcen.
So mach ich das, und es klappt. Siehe da. :eek:
So sparsam muss man auch nicht sein ... 25 x 25 - 100 x 100 Maps sind mMn vollkommen ausreichend.Zitat:
Zitat von PX
greetz
Nach meinen Beobachtungen ist die Mapgröße auch völlig egal. Grafiken außerhalb eines Viewports kosten kaum zusätzliche Rechenzeit. Wichtig sind natürlich Mapelemente die selbst dann noch Rechenzeit kosten, wenn sie sich nicht im Einflussbereich des Spielers befinden. Das trifft eigentlich nur auf Events zu. Autostartevents würde ich jetzt nicht gerade als schlimmes Beispiel nennen. Die sind eigentlich recht harmlos und werden ohnehin nur für Zwischensequenzen oder Eventmenüs gebraucht. Sie sind zumindest weniger aufwändig wie CommonEvents oder Parallele Prozesse. Aber woran es meistens scheitert sind dutzende NPCs, Schmetterlinge, Vögel, irgendwelche Kisten die man als Events platziert obwohl sie auch ins Tileset gekonnt hätten usw. Tiere lassen sich imo besser per Ruby scripten. Bei NPCs ist das schon schwieriger. Hier muss man sich wohl einfach etwas einschränken.
Das Thema dreht sich nicht darum wie man RMXP ruckelfrei oder ressourcenschonend zum Laufen kriegt, sondern warum es bei oder bessergesagt trotz 20fps so ruckelt.
Wenn man ein Anti-Lag-Script benutzt ist es auch kein Problem eine große Map mit über hundert Events zu betreten. Das Script führt dazu, dass Events die nicht im Sichtbereich sind nicht berechnet werden, das gilt auch für Events mit parallelen Prozessen. Einige Scripts unterstützen es auch eine Notiz ins Event zu schreiben damit es trotzdem, falls dies nötig ist dauerhaft berechnet wird. Ich habe damit nur positive Erfahrungen gemacht und der Nutzen lässt sich ganz einfach an einer Demo demonstrieren. Von daher kann ich auch die Kritik von PX nicht nachvollziehen.Zitat:
Zitat von -KD-
Eine Frage hätte ich allerdings noch zu dem was du gesagt hast: Wie soll man denn Tiere in Ruby schreiben? Also ich kann ihre Reaktion in Ruby schreiben und das in ein Event einfügen, aber ich muss ja trotzdem das Event setzen - gut man könnte auch die Grafik mit Ruby anzeigen lassen, aber das kommt mir arg umständlich vor.
Vllt. liegt es auch einfach daran, dass das menschliche Auge 24 Bilder pro Sekunde erfassen kann. Ab 25+ täuscht das Auge eine fließende Bewegung vor. (wird beim Fernsehn genutzt) Dann macht euch mal einen Reim darauf, was der Post mitm Thread zu tun hat :D
Das hat aber nichts mit den Augen zu tun.Zitat:
Zitat von The Alucard
Der Ursprung der 25 Bilder pro Sekunde liegt wo anders.
Erstmal zeigt ein Fernseher keine 25 Bilder pro Sekunde, sondern 50 Halbbilder pro Sekunde. (Stichwort: Interlace)
In Ländern, die NTSC Besitzen sind es sogar 60 Halbbilder pro Sekunde.
Der Ursprung liegt jeweiligen Stromnetz des Landes.
Europa (PAL) besitzt ein Stromnetz mit einer Frequenz von 50 Hz. (50 Schwingungen pro Sekunde).
z.B. USA und Japan (NTSC) besitzen ein Stromnetz mit 60 Hz.
Beim BAS Signal (Das Schwarz/Weiss Signal) wurde damals die Frequenz das Stromnetzes für die Synchronisation benutzt.
Beim heutigen FBAS Signal wurde lediglich ein Farbsignal beim Schwarz/weiss Signal hinzugefügt.