Ja natürlich geht das überall^^
Ich sagte ja auch, dass es eine Grundfunktion ist.
@BW-Gamer: Ja gut, hast schon recht. Mit Maus gehts natürlich auch^^
Ja natürlich geht das überall^^
Ich sagte ja auch, dass es eine Grundfunktion ist.
@BW-Gamer: Ja gut, hast schon recht. Mit Maus gehts natürlich auch^^
Ich weiß nicht obs schon irgendwo hier steht ( habs nicht gefunden) aber weiß jemand wie lange die Befehle "Face UP", "Face Down" .... dauern?
Wenn du die Zeit für einen Wait brauchst: Gib einfach 0.5 Sekunden ein, das müsste genügen.
Die Verwendung der Show Picture Picture Befehle des RPG Maker 2000 und 2003 kostet sehr viel Systemleistung. Dies hängt zwar auch von der Größe des Bildes ab, aber auch wenn es sich nur um kleine Bilder von 16x16 Pixeln handelt, fängt das Spiel (besonders auf etwas älteren Rechnern) an zu stocken, sobald man mehrere dieser Befehle kurz hintereinander ausführt. Bei größeren Bildern kann es wie gesagt auch schon bei nur einem Show Picture Befehl auf älteren PCs zu einem kurzen, rapiden Einbruch der Framerate kommen.
Dies war übrigens das größte Problem bei einem meiner Kampfsysteme, bei denen ich Gegner und Held durch Bilder anzeigen ließ.
Die Lösung hierzu mag zuerst banal erscheinen. Einfach keine Show Picture Befehle verwenden!
Solange man ein Bild nur bewegen muss, kann man dies ja bequem und ohne Ruckeln, per Move Picture Befehl. Aber was soll man machen, wenn man eine andere Animationsphase anzeigen möchte? Wie kommt man nun um den Show Picture Befehl herum?
Man könnte einfach alle benötigten Animationsphasen einmal zu Beginn des Spiels per Show Picture anzeigen lassen, dadurch würde es einmal am Anfang (vielleicht beim Betreten der Map) zu einem Einbruch der Framerate kommen.
Dann könnte man einfach die benötigte Animationsphase per Move Picture Begfehl anzeigen lassen und nicht benötigte per Move Picture Befehl mit 0.0 Wait auf transparent schalten (oder besser noch außerhalb des Bildschirmausschnittes bewegen), so kann man, allein durch Move Picture Befehle, immer zwischen einzelnen Bildern (Animationsphasen) wechseln, ohne Show Picture Befehle verwenden zu müssen. Diese Idee hab ich btw von ZidanneFFIX ^^'.
Der Schwachpunkt dieser Methode ist aber offensichtlich. Man kann nur maximal 20 (rm2k ohne Patch) bzw. 50 (rm2k3) verschiedene Animationsphasen per Show Picture gleichzeitig zu Beginn anzeigen lassen.
Dies ist natürlich recht wenig, so dass man meist doch gezwungen ist, hier und da mit Show Picture Befehlen zu arbeiten.
Aber auch dafür gibt es eine Lösung! Man könnte einfach ALLE Animationsphasen einer Spielfigur, in bestimmten Abständen, in einer Reihe untereinander auf ein einziges Bild packen. Diese Abstände müssen so groß sein, wie der Bildschirm hoch ist, sodass niemals zwei Animationsphasen gleichzeitig auf dem Bildschirm zu sehen sein können. Diese Zwischenräume müssen dann natürlich auch, dank transparenter Farbe, durchsichtig sein.
Hier ist zB. ein Beispielbild, auf das 4 Animationen (rot gekennzeichnet) mit 16x16Pixel Größe passen würden (Weiß muss hier die transparente Farbe sein):
Will man nun eine andere Animation anzeigen, muss man das Bild einfach nur, per Move Picture Befehl, in Y-Richtung verschieben. Diese Verschiebung soll natürlich abrupt sein, also sollte man hier den schnellstmöglichen Move Picture Befehl mit 0.0 Wait wählen. Zu beachten ist aber, dass man dann nicht unmittelbar danach im Code einen weiteren Move Picture Befehl verwenden kann, da sich Move Picture Befehle ja überschneiden (was ja sicher den meisten bekannt ist). Man müsste also nach diesem Move Picture 0.0 Wait Befehl auch den Code um 0.0 Wait unterbrechen (zb. durch einen entsprechenden Wait Befehl), bevor man weitere Move Picture Befehle, die sich auf dieses Bild beziehen, ausführt.
Neben dem "Performanceboost" ist es auch unglaublich praktisch, alle Animationsphasen auf einem einzigen Bild zu haben. So kann man Animationen per Variable über ein und denselben Move Picture Befehl ansprechen, wo dies vorher nur durch unterschiedliche Show Picture Befehle möglich war und wenn man mal was an seinen Animationen ändert, muss man nur ein Bild neu drüberkopieren, und nicht zig Bilder neu importieren.
Die Idee hab ich übrigens von Zeph (hier afaik unter DR_Zeph registriert, Dank an ihn!).
Hier noch ein paar Anmerkungen dazu, die ich schon im Quartier gepostet habe:
Zitat von Ryo Saeba
--The illusion or impression of never having experienced something
that has actually been experienced many times before
Geändert von Ryo Saeba 1000 (01.03.2007 um 13:50 Uhr)
Sehr nützlicher Hinweis.
Vorallem wenn es sicher keinen Map tree Data Error gibt ^^
Das ganze wäre in KS und Menüs sicher extrem hilfreich, spart nochdazu
Systemressis (und Speicherplatz??, werd das mal mit einem Grafikprog ausprobieren)
Wenn man auf Nummer sicher gehen will muss man halt ein 640x480 Pic
importieren. Darauf würde man aber nur 4 Animationsstufe bringen.
Obwohl es auch schon bei 4 Stufen hilfreich wäre, weiß ich jetzt nicht
ob sich das von der Größe(wahrscheinlich minimaler Unterschied) rentieren würde.
Aber der Übersichtlichkeit würde wegen wäre es sicher überlegenswert.
Heißt dass, so lange auch nur ein einziger Pixel eines Bildes im Bildschirmausschnitt ist, wird die Systemleistung beansprucht, aber sobald
es außerhalb des Bildschirmausschnitts ist braucht es keine Systemleistung mehr
(braucht es keine oder weniger Systemleistung)
Eine Frage hätte ich da noch:
Ich gehe da mal von meinem Pic aus.
Sagen wir der rote Punkt wäre ein Menüpunkt und ich will ihn mit 4 animationsstufen einblenden lassen. Wenn ich das jetzt per Move Pic Befehl mache würde es sicher weniger Systemressis brauchen, da das Pic aber größer ist wieder mehr und somit wäre es egal ob man ein 4x320 oder 1x640 verwendet.
Deine Methode gefällt mir btw super, aber es ist einfach ein bisschen unsicher
wegen dem importieren.
~Waradience~
Wenn.. wie gesagt kann ich da nichts garantieren, bei mir trat dieser Fehler jedoch noch nicht auf und ich arbeite schon eine geraume Weile mit dieser Methode.
Wenn du auf der sicheren Seite sein willst, kannst du natürlich auch bis zu vier Animationsphasen auf ein Bild packen, dass nicht die 640x480 Grenze übersteigt.
Das Bild sollte aber bei vier 16x16 Pixel Animationsphasen nicht so wie das von dir gepostete Aussehen, sondern, damit du die optimale Performance (geringste Bildgröße bei maximaler Anzahl Animationsphasen) herauskriegst, so:
Das ist immer noch definitiv besser, als die vier Animationsphasen per Show Picture zu realisieren, was die Performance angeht.
Hä? Angenommen deine Animation ist nur dieses rote Quadrat, dann brauchst du, wenn du die althergebrachte Show Picture Methode verwendest, auch nur ein 16x16 Pixel großes Quadrat anzeigen und kein 320x240 Pixel großes Bild.
Daher sollte die Frage lauten:
zeigt man die Animationen mit
a) vier Bildern (je 16x16 Pixel) per Show Picture Befehlen an oder
b) mit einem Bild (352x272 Pixel) per einmaligem initialisierenden Show Picture Befehl und anschließenden Move Picture Befehlen.
Und auch hier ist die zweite Variante weniger leistungshungrig.
Einzig die Initialisierung des Bildes (Show Picture Befehl beim betreten der Map) kann kurz ruckeln auf älteren Rechnern, die Move Picture Befehle dürften aber dennoch weit weniger Leistung kosten, als die Show Picture Befehle, trotz der Größenunterschiede der Bilder.
--The illusion or impression of never having experienced something
that has actually been experienced many times before
Interessant zu wissen. Für mein Spiel aber nicht praktikabel aus verschiedenen Gründen...
Ich habe dafür eine Funktion eingebaut um bestimmte Grafikeffekte abschalten zu können sodass mein Spiel auch auf schwächeren PC's problemlos laufen sollte.
Aber mal eine andere Frage, es ist möglich die Größenangaben des Makers zu überschreiten. Und zwar indem man ein Bild importiert, und diese Datei dann mit einem Bild das größer ist als die Grenzen des Makers überschreibt.
Hab's ein paar mal ausprobiert, und geht wunderbar. Auch der Befehl bezüglich der Bildgröße bei Show- oder MovePicture wird problemlos ausgeführt.
Das Wäre für Lichteffekte auf Maps größer als 20x15 Feldern äußerst praktisch, meine Frage wäre nun inwieweit das die Performance beeinträchtigt bzw. zu Fehlern führen kann wenn man den Maker gelinde gesagt verarscht?
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Das ist afaik noch vollkommen unerforscht.
Der sogenannte Oversizeimport scheint bisher auch bei uns gut zu funktionieren.
An sich ist sowieso fragwürdig wie der Maker das importieren eine Ressource registriert. An sich scheint er dies nämlich nicht zutun.
Keine Makerdatei wird größer beim importieren einer Datei. Dies würde man jedoch denke ich erwarten können bei einer Art von Index.
An sich kannst du eventuell die Vorsichtsmassnahme einführen das du das ganze nur bei ausgeschaltetem Maker durchführst. Allerdings benutzt man die Methode wirklich auf eigene Gefahr.
--
Was ist mit den Bildern selbst? Weil irgendwas muss geschehen, immerhin wählt man ja die transparente Farbe beim Import, wenigstens das muss ja gespeichert werden irgendwo, und wenn in der Datei selbst
jop, die transparente Farbe steht im Bild selber als Farbindex 0, ansonsten könnte man ja auch keine transparente Farbe in PSP bestimmen, die der Maker anerkennt. Afaik geht der Maker hin und kontrolliert beim Importieren nur, ob die Datei den entsprechenden Größenverhältnissen entspricht und ob das Bild die richtige Farbtiefe hat. Arbeite ebenfalls mit diese Methode und habe noch nie ein Problem mit dem Maker gehabt, weil er sich über ein solches Picture beschwert.
Es soll ja bei nicht importierten Dateien fehler geben können. (jetzt nicht auf die Technik bezogen sondern allgemein auf das importieren). Und das soll angeblich auch mehrfach getestet worden sein und sich als wahr heraus gestellt haben.
Wenn aber keine Datei des Projektes beim Import größer wird, kann das doch eigentlich absolut nicht sein. Dann hätte ich es mir nämlich ersparen können 300 dateien am Stück zu importieren >_<
Meine Erfahrung nach kontrolliert der Maker ledeglich wenn eine Datei benötigt wird ob sie sich im RTP Ordner oder im Projekt befindet und gibt ggf. ne Fehlermeldung raus.
Davon mal abgesehen das der "Importfehler" nicht immer beim reinkopieren Auftritt sondern nur manchmal, frage ich mich wie man das gezielt testen können will/wollte.
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Es ist einfach kurios.
An sich scheint die Importfunktion nur dafür da zu sein das man die transperente Farbe auswählen kann und natürlich zur Kontrolle der "Maße" für Makergrafiken.
Sprich das man die Grafiken auf die entsprechende Größe und Farbtiefe setzt.
Darum ist es absolut nicht beantwortbar warum der Maker deswegen Fehler produziert. Und ob die Fehler davon kommen. Ne aktuelle Theorie ist ja das der Maker einfach aus sein muss beim hineinkopieren. Wobei auch das fragwürdig ist.
An sich kann man einfach nur sagen das der Maker anscheinend keine Fehler produziert wenn man importiert. Alles andere muss man auf eigene Gefahr betreiben. Diese würde ich nun z.B. nicht für das Projekt von Corti und mir eingehen wollen.
Darum importiere ich im Technikprojekt alle Grafiken schön brav. Später beim zusammensetzen der Technik mit dem Grafikteil zerstört ein eventueller Fehler von der Grafikseite aus nicht die gesamte Technik.
--
Berechtigungen
Zitieren
