(23.09.2012, 11:06)Hendrik schrieb: [ -> ]Nach ein wenig Recherchen zum GIF-Format habe ich festgestellt, dass GIF ziemlich viel von dem unterstützt, was wir benötigen: Animationen, Teilbilder mit eigener Startposition/Größe und Anzeigedauer. Was leider fehlt, sind Namen für die einzelnen Frames, die könnte man zur Not in einem Kommentar speichern.
Die einzigen Alternativen zu GIF, die mir einfallen, sind
APNG und
MNG. Gibt es überhaupt noch andere?
(25.09.2012, 13:04)Boneman schrieb: [ -> ] (23.09.2012, 11:06)Hendrik schrieb: [ -> ]Nach ein wenig Recherchen zum GIF-Format habe ich festgestellt, dass GIF ziemlich viel von dem unterstützt, was wir benötigen: Animationen, Teilbilder mit eigener Startposition/Größe und Anzeigedauer. Was leider fehlt, sind Namen für die einzelnen Frames, die könnte man zur Not in einem Kommentar speichern.
Die einzigen Alternativen zu GIF, die mir einfallen, sind APNG und MNG. Gibt es überhaupt noch andere?
Nicht, dass ich wüsste. Und APNG/MNG sind einfach noch nicht so verbreitet - so wie generell diese Animationsformate etwas stiefmütterlich behandelt werden - GIMP z.B. kann zwar GIF-Animationen bearbeiten, aber das ist eher so eine Notlösung über Ebenen-Namen.
Hallo liebe NLT-versierte forenvollmitglieder
dieser thread ist zwar schon eine weile inaktiv,allerdings bin ich sehr an dem inhalt interessiert,vorallem was die deaktivierung des nervigen rechtsklick-sounds angeht.
nach einiger suche im internet bin ich erstaunt, eine seite gefunden zu haben,auf der beschrieben wird,wie dieses kleine,unangehme,teilweise spielspaß-raubende übel ausgemerzt werden kann.
bedauerlicherweise benötigt man den status eines vollmitgliedes, um anhänge herunterladen zu können. da ich zwar gerne foren zur lösung technischer und spielerischer probleme konsultiere,jedoch selten aktiv in foren unterwegs bin und mir momentan auch die zeit fehlt,um aktiv in einem zu schreiben, werde ich wohl kaum den status eines vollmitgliedes erreichen.
wenn es irgendeine möglichkeit gibt,mir das nötig modding-tool zum austausch der sounddatei fx3.voc, was in diesem fall wohl das "nltpack-beta2.zip"wäre,zukommen zu lassen,wäre ich äußerst dankbar und sofort wieder bereit,in die tiefen aventuriens einzutauchen und grimring zu suchen. derweil,vorallem bei kämpfen,stört mich der sound jedoch allzu sehr
hoffe auf euer verständis
Phex zum Gruße
Garret
Hallo Garret,
wenn du dir zutraust, es selbst zu kompilieren, gibt es nltpack auch auf
Github.
Mal eine ganz gemeine Frage: Angenommen, das Schicksalsklinge (hoffentlich NLT)-Remake würde moddingfähig, wäre damit BrightEyes obsolet? Bzw. bestünde eurerseits Interesse, an beiden Versionen zu modden?
für mich ist Bright Eyes trotzdem noch ein wichtiges Projekt
Die "alte" wird für mich immer ihren Flair und ihre Einzigartigkeit behalten. Mit BrightEyes kann man Schick bereits jetzt mit weniger DosBox-Power laufen lassen. Man müsste mal ausprobieren, ob das auf Netbooks oder anderen schwächeren PCs einen bemerkbaren Unterschied ausmacht. Die kleineren Bugfixes an Schick sind natürlich eine sehr nette Dreingabe.
Edit: Interessanterweise schein BrightEyes etwas mehr Arbeitsspeicher zu brauchen. 61.000K Arbeitsspeicher für DosBox vs 69.000K Arbeitsspeicher für BrightEyes im Taskmanager. Andererseits läuft BrightEyes eben mit weniger Cycles (400 statt 3000).
Für mich bleibt das Original das Original. Ob die NLT HD überhaupt irgendwie daran heranreichen wird, bleibt abzuwarten. Mit Sicherheit ist das Modding der original NLT technisch interessanter.
@Obi: Andere Algos mit anderen Speicheranforderungen. Kein Wunder, wir brauchen ja heute kein Kamel mehr durch 640kB zu treiben.
Dass BrightEyes mehr Speicher benötigt als DosBox, ist klar - es ist ja eine Erweiterung der DosBox mit eigenen Datenstrukturen, die noch oben auf den von der DosBox benötigten Speicher draufkommen. Wenn BrightEyes mal fertig ist und man den DosBox-Code entfernen kann, wird das sicherlich besser. Bis dahin wird allerdings der Speicherbedarf eher noch steigen, und ich habe Zweifel, dass unsere nachgebaute Version speichereffizienter ist als das Original.
Heute hat man einfach so viel Speicher zur Verfügung, da sind selbst ein paar Megabytes mehr auch auf kleinen Geräten noch zu verschmerzen. CPU-Last hingegen ist nach wie vor interessant, zumindest zur Energieeinsparung.
EDIT: Was meine Motivation bzgl. BrightEyes angeht: Ich muss zugeben, dass die Ankündigung der NLT-HD meine Motivation etwas verringert. Um so mehr, wenn das Ergebnis überzeugt. Mein Interesse galt von Anfang an allerdings eher Sternenschweif als der Schicksalsklinge, insofern muss sich dieser Teil der NLT-HD (der hoffentlich kommt!) mit dem Original messen. Trotzdem, das heißt nicht, dass ich nun gar kein Interesse mehr an BrightEyes bzw. dessen Sternenschweif-Teil hätte. Das Reverse-Engineering macht nach wie vor Spaß, und weniger sporadisch als momentan kann ich sowieso kaum noch dran arbeiten ;-D
Hallo, ich habe, wie oben schon angedeutet, an einem universellen Bildkonverter gearbeitet, der alle Bildformate der NLT nicht nur in verbreitete Grafikformate wie GIF und TGA umwandeln kann, sondern diesen Schritt auch umkehren kann, sprich, NLT-Bildformate erzeugen.
Ich habe gerade eine erste Version von diesem Tool ins BrightEyes-Repository geschoben. Momentan werden folgende Formate unterstützt:
- Laden von ACE (teilweise), AIF, NVF, RAW
- Speichern von GIF, TGA, NVF
Das Laden von GIF und TGA-Dateien wäre der nächste Schritt. Bei ACE-Dateien werden momentan nur Einzel-Animationen (ASS-Subformat) unterstützt, mehrere Animationen (SEQ-Subformat) sind noch nicht möglich.
Das Tool heißt
any2any und liegt im BrightEyes-Repository unter
tools/nvf2tga, da es aus den nvf2tga-Tools entwickelt wurde und diese ersetzen soll.
Die Bedienung ist recht einfach: Nach dem Kompilieren kann man mit
Code:
bin/any2any Eingabedatei Ausgabedatei
konvertieren. Wird ein Format (noch) nicht unterstützt, bricht das Programm mit einer entsprechenden Fehlermeldung ab. Wenn man von einem Mehrbilder-Format (z.B. ACE oder NVF) in ein Einzelbild-Format (z.B. TGA) schreibt, wird den Ausgabe-Dateinamen eine laufende Nummer hinzugefügt.
Als kleine Demonstration habe ich mal eine Animation aus Sternenschweif (MAG_BOOK.ACE) als GIF-Datei angefügt.
[
attachment=3564]
Lassen sich die bearbeiteten Bilder dann nur in der selben Größe (Auflösung) wie die Originaldatei wieder einbauen, oder könnte man dann auch gleich die Auflösung (bei gleichbleibenden Seitenverhältnissen) erhöhen?
(15.09.2013, 13:32)aeyol schrieb: [ -> ]Lassen sich die bearbeiteten Bilder dann nur in der selben Größe (Auflösung) wie die Originaldatei wieder einbauen, oder könnte man dann auch gleich die Auflösung (bei gleichbleibenden Seitenverhältnissen) erhöhen?
Nein, das geht nicht. Dazu müsste ja das Spiel diese höhere Auflösung unterstützen. So etwas geht bestenfalls mit Texturen (in Schweif wären das die .RAW-Dateien), und auch da bezweifle ich, das Schweif/Riva mit höher aufgelösten Dateien klarkommen.
Hmm leider, gibt es ein Problem beim Kompilieren:
Code:
/BrightEyes/tools/nvf2tga> make
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/pp20.o src/pp20.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/rle.o src/rle.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/rl.o src/rl.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_nvf.o src/loader_nvf.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_ace.o src/loader_ace.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_aif.o src/loader_aif.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_raw.o src/loader_raw.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_bob.o src/loader_bob.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_gif.o src/loader_gif.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_tga.o src/loader_tga.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -c -o ./build/loader_uli.o src/loader_uli.c
gcc -g -std=c99 -Iinclude `pkg-config --cflags GraphicsMagick` -o ./bin/any2any src/any2any.c ./build/pp20.o ./build/rle.o ./build/rl.o ./build/loader_nvf.o ./build/loader_ace.o ./build/loader_aif.o ./build/loader_raw.o ./build/loader_bob.o ./build/loader_gif.o ./build/loader_tga.o ./build/loader_uli.o `pkg-config --libs GraphicsMagick`
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ./bin/any2any: Datei oder Verzeichnis nicht gefunden
collect2: error: ld returned 1 exit status
make: *** [any2any] Fehler 1
Mmh, sieht so aus, als ob der Compiler das Verzeichnis ./bin nicht findet. Wenn du von Hand ein solches Verzeichnis anlegst, müsste es klappen. Ich werde mal die Makefile entsprechend anpassen, dass das in Zukunft automatisch passiert.
Funktioniert!
Nur die Farb-Palette scheint vielleicht durcheinander zu sein, da die Farben in der Ausgangsdatei / Gif-Datei nicht stimmen.
(16.09.2013, 14:41)Obi-Wahn schrieb: [ -> ]Funktioniert! Nur die Farb-Palette scheint vielleicht durcheinander zu sein, da die Farben in der Ausgangsdatei / Gif-Datei nicht stimmen.
Mit welcher Datei hast du es denn ausprobiert, Obi-Wahn? Dann kann ich versuchen, den Paletten-Fehler zu korrigieren.
Bei der Gelegenheit sollte ich vielleicht erwähnen, dass (noch) nicht alle NVF-Dateien aus Schicksalsklinge unterstützt werden. Schick nimmt es mit den NVF-Dateien nämlich nicht so genau: Manchmal fehlen (Teile der) Farbpaletten oder die Header sind verstümmelt (weil bestimmte Bildinformationen, die im Header enthalten sein müssten, hard-coded in der SCHICKM.EXE liegen).
EDIT: Korrigiertes Makefile ist jetzt online.
GUERTEL.NVF habe ich verwendet. Aber wenn manche Dateien nicht vollständig sind, erklärt das ja vieles.
In nvf2tga gab es Code, der extra für diese Dateien besondere Paletten (hard-coded) eingebunden hat. Diesen Code habe ich jetzt für any2any verfügbar gemacht (bitte nicht fragen, wie, ist ein schmutziger Hack).
Mit anderen Worten, die NVF-Dateien von Schick müssten jetzt auch korrekte Farben haben. Für GUERTEL.NVF und GGSTS.NVF habe ich das schon getestet.
Auch wenn es schmutzig ist, ... es funktioniert!
Habe gerade eine neue Version hochgeladen, die jetzt auch das Laden von ACE-Dateien mit mehreren Sequenzen (also mit SEQ-Header) unterstützt. Die Sequenzen werden vorerst einfach alle hintereinander gehängt, bis mir was Besseres einfällt.
Betroffen davon sind in erster Linie die Kampf-Sprites.