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
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.
--
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
--
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
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.^_~
--
~
Geändert von Tiro&Millet (16.06.2007 um 11:03 Uhr)