Detail-Wissen und Geheimnise des RPG-Makers -vorallem für Erfahrene/Profis lehrreich

Zitat:

---

Zitat von Waradience

Sehr nützlicher Hinweis.
Vorallem wenn es sicher keinen Map tree Data Error gibt ^^

---

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:
http://img404.imageshack.us/img404/9744/4anisminld3.png

Das ist immer noch definitiv besser, als die vier Animationsphasen per Show Picture zu realisieren, was die Performance angeht.

Zitat:

---

Zitat von Waradience

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.

---

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.

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?

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.

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.

Hab eine Frage für die Pros. Wieviele 0.0 Waits dauert ein Jump im 2K?

Die Frage hatte Lachsen irgendwo weiter vorne schon beantwortet:

8x Slower -- 32x 0.0 Sec = ca. 0.5 Sec + 2x 0.0 Sec
4x Slower -- 22x 0.0 Sec = ca. 0.3 Sec + 4x 0.0 Sec
2x Slower -- 16x 0.0 Sec = ca. 0.2 Sec + 4x 0.0 Sec
Normal ----- 11x 0.0 Sec = ca. 0.1 Sec + 5x 0.0 Sec
2x Faster -- 8x 0.0 Sec = ca. 0.1 Sec + 2x 0.0 Sec
4x Faster -- 4x 0.0 Sec

Die Sprünge sind also langsamer als das normale Bewegungstempo. Interessant.

Nein, so ist das nicht zu verstehen. Das normale Bewegungstempo wird "pro Tile" gerechent. Das Sprungtempo "pro Sprung". Egal wie weit der Sprung ist, er dauert immer gleich lang.

Klar, ich bin auch von einem Sprung zum Nachbartile ausgegangen. Wenn man über die ganze Map springt, ist es natürlich schneller.

mal ne frage ... kann es sein dass eine .png datei eine mindestanzahlt von farben haben muss damit es importierfähig ist?
also die palette zumindest...weil wenn man eine pallette hat nut mit zwei farben und dieses bild importieren will kommt die fehlermeldung : unsupported png format

Zitat:

---

Zitat von Chimaera

mal ne frage ... kann es sein dass eine .png datei eine mindestanzahlt von farben haben muss damit es importierfähig ist?
also die palette zumindest...weil wenn man eine pallette hat nut mit zwei farben und dieses bild importieren will kommt die fehlermeldung : unsupported png format

---

müssen glaub ich genau 256 Farben sein (auch bmp)

Suche nach "unsupported".

Kam schon öfter vor.:)

Edit: Okay, kann man wohl nicht verlinken, obwohl da ne feste ID steht. Naja, keine Ahnung, aber man kann ja auch selber unsupported in der Suche eingeben.^_~

@Tiro&Millet:
Da kommt bei mir nur "Diese Suchanfrage erzielte keine Treffer"^^

@Chimaera:
Also ich hab einige Grafiken im Spiel, die nur 2 Farben (nämlich schwarz und weiß) aufweisen. Es kann aber sein, dass du 2^x Farben brauchst, damit der Maker die Grafik erkennt, z.B. 2, 4, 8, 16, ... , 256.

ich hab mal ein 4 farbige grafik erstellt, und sie auf 256 farben runtergerechnet. erbiebt ne menge schwarz, oder weis, aber es sind 256 farben.

@Größe und impeortieren,

ich hatte noch keine probleme damit. das importieren dient auch dazu das format festzulegen. man kann also per import bmp in png, oder xyz umwandeln, warscheinlich ist das ein relikt aus zeiten, wo manche bildbearbeitungsprogramme png nicht gelesen haben.

ich weiss jetzt nicht ob das jetzt hierhin gehört,aber ich hab was rausgefunden^^


wenn man beim RM2003 bei "Kampfstile" die "Texttabelle" auf "transparent" stellt,
ist die Textbox im ganzen Spiel transparent,ausser natürlich das Menü und das hauptmenü

Hab nochwas xD

also,
drückt man Im Spiel F5,dann wird das Bild auf 320x240 geschrumpft,also,dass es nicht mehr so riesig ist.

:D F4 man xD und ich habe auch noch was.
Wenn man versucht chara-sets zu machen und imoment glaubt das man Hilfe braucht muss man es erst selber probieren.
Templates:unter Chara-Projects gibts menge Templates wer faul ist kann gleich einen Chara im Generator fertig machen.Wenn man nicht weiß wie groß so ein Chara-set ist dan unter rpg 2000 die Templates downloaden.Das gleiche kann man mit den Face-sets machen.Und 256 Farben verwenden nicht vergessen ^^.